Kaspersky OS

You can install and run OpenBSD on DO. Here's the guide by Derek Sivers: http://50pop.com/d.html

"but I think that the commodity level of most hardware still makes it super unlikely." "If a company is willing to use Office 365"

Oh I'm with you on this. Steve Walker's Computer Security Initiative and the Orange Book gave us lots of highly-secure stuff for defense, etc. They got rid of that for cheap, fast, fully-featured COTS. The same happens in business, aerospace, etc. The exceptions are usually pre-made appliances or, in aerospace, better components in the DO-178B Level A stuff. Much of it is shoddy. A good chunk of the defense fabs' business is probably replacing legacy parts in old equipment at prices guaranteed through corrupt contracts. They don't give a shit about security in general: just money. ;)

"But when it comes right down to it, there's billions of weak points at much higher levels and much more easily compromised than a chipset or compiler."

There's lots of weak points. Stopping code injection from all known vectors with simple, proven techniques at CPU and language levels eliminates the whole malware problem if apps are whitelisted, built from source, and include no executable scripting/JIT. There's ways to conveniently enforce POLA within a system (eg CapDesk), do secure (even automated) configurations of networks (Boeing's Survivability Grammers), and so on. There's components for most use-cases just waiting to be productized, integrated and sold to larger audience. Given this is 90+% of attacks, it's certainly worth pushing to establish a stronger baseline for companies that want less loss of secrets, availability, data, etc.

There's only so much the traditional methods like coaching and monitoring can do if one can simply open a folder (not a file!) that immediately results in full-control of machine by malware since a thumbnail rendered. Endless crap like that exploiting underlying foundation of quicksand. The HW and SW of endpoints, at least at lowest layers, need to get in check for that other stuff to be meaningful. I'm also in favor of an integrated networking stack that makes different applications, even if using TCP or HTTP, look visibly different at the packet level so NIDS spots weird patterns more easily. Like the MLS extension but not MLS policy itself. Do it at application layers with stuff like Ethos's eTypes or security-enhanced ZeroMQ where developers don't worry about plumbing much.

" It's a good academic exercise though."

It's also an industry bringing in tens of millions of dollars at least. That's with costs that are too high, lack of key software support, and little to no advertising. I imagine it could be larger than tens of millions with such obstacles reduced or eliminated.

The thing that really scares me, as a fortunately ex-security guy, is the fact that everywhere I've worked for the last 10 years people are super casual about keyboards and mobiles.

Mobile phones are an amazing platform to do... well, almost anything. There are some areas where their possession is restricted, though I suspect a motivated party could sneak a stripped down mobile device into nearly anywhere.

Keyboards, on the other hand. Wow. I've seen even airgapped systems have random keyboards right off the pallet slapped onto them. These sit in racks for months or years, then get tossed usually to a recycler, a donation program, stolen, or just thrown into a dumpster. Considering how much tech is in a keyboard, and how much volume it has, you could place nearly anything in there and possibly go ages without catching on.

A scenario that I recently pointed out as a 'thought exercise' was a refitted USB keyboard with a microphone, pinhole camera, and simple keylogger+screenshot engine that contained an intermittent RF/wifi/bluetooth/ultrasonic network. Programmed to dump its payload whenever an individual passed nearby and triggered it remotely.

Such a trojan could sit in a datacenter or conference room for years completely unnoticed. The data it captured transmitted only to the cleaning crew or whatever.

Worse yet, such a device could also pass instructions to the system it was attached to as an actual USB device.

You could fit a lot of horsepower in an innocuous Dell or MS or whatever mass-produced keyboard. Toss it into a top level conference room for corporate espionage, toss it into a data center for more direct trouble, whatever.

Scary thought, and I think part of why I still use the same keyboard I've had since 1997 ;)

Thanks! I think I'll give that a try. That's a great idea.

> Those get fixed.

This has been done, but poorly and only for an extremely select few things. KASLR is just one example of a poorly implemented feature that pales in comparison to alternatives (completely subsumed by features in the grsec implementation, for example, since it only randomizes things like .text addresses. Maybe some of that got fixed.) Features like kptr_restrict can easily be subverted by a number of trivial infoleaks unless you back it up with a lot of other protections, etc.

Other things like __ro_after_init for read-only post-init memory have only recently been incorporated into arch/x86 (in the past few months AFAICS, so likely kernel 4.8+ only) since being available for nearly a year on x86 at least. I'm not sure if they fixed the fact __ro_after_init apparently didn't work on loadable modules. grsecurity's implementation is better anyway (allowing remarking variables as writeable for short windows), but I'll concede that extra power relies on KERNEXEC, which breaks some userspace things.

I don't think they botched the LATENT_ENTROPY plugin, at least...

If you actually look at the details, Linux has a pretty bad track record as far as "meaningfully implementing defenses" goes, considering how long this stuff has been around. It's better than literally nothing, I guess.

> There are places where the kernel could be further hardened, but would break software.

Uhhhh, sorry, but you need to do your research. There are plenty of places that could be improved without breaking userland at all, while still mitigating many classes of exploits. PAX_REFCOUNT is one example (a variant of which will probably soon go upstream in some weird way, of course). RANDSTRUCT, PAX_MEMORY_STACKLEAK, KSTACKOVERFLOW, JIT_HARDEN, RAND_THREADSTACK... If you're determined to fix the FPs, the SIZE_OVERFLOW plugin qualifies, too (it occasionally hits false positives, murdering an otherwise legitimate task, but this is a different scenario to a feature outright breaking userspace, and it's caught many bugs and can stop many actual exploits on its own).

There are probably at least a dozen major features in grsecurity that don't have to compromise userspace, and still aren't implemented in Linux, with no equivalent, and no timeline on the horizon. I'm not sure what to take away from this assessment of yours that the only remaining improvements will break things, other than you aren't really aware at all of what the current defense landscape looks like...