Slashdot Mirror

A noble effort, but tools like ASLR have in practice shown themselves to be less than bulletproof. They're worth pursuing to an extent, but they aren't enough for a truly robust preemptive security strategy and shouldn't be our primary focus.

The future of secure computing is obviously a ground-up microkernel affair that allows strong sandboxing. But that's going to take... a while to mature, in terms of native application support. In the meantime, a stopgap using paravirtualization and hardware assisted virtualization is the best that can be done. It's not as efficient, but it's a lot snappier than you'd expect and silicon is cheaper than programmers' time.

The basic security idea of Qubes (putting aside its UI innovations, which obviously aren't important on embedded devices) is that Dom0[1] entirely lacks networking, including the networking driver. The networking driver is isolated in its own VM with its own separate kernel, and on a vt-d capable machine that VM's access to shared resources is controlled (meaning you can't use a DMA attack to access another VM's data from RAM.) After the networking VM comes a separate firewall VM, and other VMs can have connectivity through the firewall VM.

This is pretty damn robust, but in this scenario you could and should do even better by modifying Dom0[2] to verify commands and/or update signatures for your mission-critical VM. Dom0 itself should never be accessed or updated over the network (and it doesn't need to be, since it isn't vulnerable to remote exploits and isn't directly involved in whatever the main functionality of the medical device is.)

Assuming we can't rewrite everything from scratch to function in a pure microkernel universe (with no VMs), the best we can do right now is to have completely separate OSes with separate kernels, connected and coordinated by a hypervisor. There's still the very real possibility of a Xen exploit (which would need to be stacked with other severe Linux exploits to be useful), but Xen is less than 150,000 lines of code and should be easier for security folks to reason about than the Linux kernel.

This all may not be viable for implanted devices due to the added power requirements but for external devices... why the hell not? The extra hardware required would surely be less than $100 wholesale, on a device that probably costs thousands.


1. With Xen, this is roughly comparable to the "host OS" used with type II hypervisors like Virtualbox, VMware, KVM / QEMU, but there are important differences. Namely, it's possible for device drivers to be located in unprivileged domains instead of Dom0.

2. Or perhaps another VM without network connectivity at all, using a more limited mechanism of data passing along the lines of Qubes' VM-to-VM copy mechanism.

Analogy time: Imagine homes with no Circuit Breakers. Any short circuit anywhere could burn down a house. Lawyers and lawmakers arrive on the scene and declare that everything you want to plug in needs to be short proof. Every product has to be certified not to burn down houses, no matter what failure happens. The designers of even a simple lamp can end up being charged with murder, and as a result nobody really wants to use electricity.

We have circuit breakers, which limit the amount of current to be supplied to an appliance. If you have a special big appliance, like an air conditioner, you have to use a special circuit to supply it with power. Circuit breakers serve to limit the side effects that are possible when you use electricity.

There is no analogous circuit breaker in our widely used operating systems. When you run an application as a user, ALL of your authority is given to the program, and you have to just hope that it does the right thing. There are systems which do place limits on the side effects of a program when you run them, and they are even user friendly and fairly easy to understand.

It's up to us to start to use operating systems that have the ability to limit the side-effects of programs. One example is the Genode project. There is also the perennially late GNU Hurd

HURD versus Linux is pretty clear; HURD's a microkernel and Linux is not. What makes HURD interesting compared to Genode's L4 kernel? At a glance, they seem to be doing more similar things.

I can't answer your question, but I just googled "genode" to find out what the heck it is. Holy crap! While Hurd has been masturbating for almost two dog LIFETIMES, Genode/seL4 have been cleaning up.

Here is VirtualBox running beside the Seoul VMM (virtual machine monitor) on top of Genode/NOVA. Seoul executes Tinycore Linux as guest OS. VirtualBox executes MS Windows 7. Both VMMs are utilizing hardware virtualization (VT-X) but are plain user-level programs with no special privileges.

HURD versus Linux is pretty clear; HURD's a microkernel and Linux is not. What makes HURD interesting compared to Genode's L4 kernel? At a glance, they seem to be doing more similar things.

I can't answer your question, but I just googled "genode" to find out what the heck it is. Holy crap! While Hurd has been masturbating for almost two dog LIFETIMES, Genode/seL4 have been cleaning up.

Here is VirtualBox running beside the Seoul VMM (virtual machine monitor) on top of Genode/NOVA. Seoul executes Tinycore Linux as guest OS. VirtualBox executes MS Windows 7. Both VMMs are utilizing hardware virtualization (VT-X) but are plain user-level programs with no special privileges.

Time to sandbox every data stream in a separate sandbox.

This OS does it from the ground up.

http://genode.org/

Multi-Level Security was worked out in the late 1960s in order to allow computing both Secret and "Top Secret" information in the same computer at the same time. The use of the Bell-LaPadula model ensures that a lesser privileged user can never cause grief for a more privileged user. If we had Mutli-Level secure systems, we could safely run any program we want in a sandbox, and it could never, ever crawl back out of it.

The closest you're likely to approach is if you enable the MAC option in FreeBSD, which is experimental.

The Genode project aims to provide a capability based security system which can run Linux Apps... it is the best chance I see going forward for a truly secure system that isn't military grade. In such systems, you specify at run time exactly which files can be accessed by an application. This has the benefit of explicitly limiting the side effects of said application, and thus making for a far more secure system. You might be tempted to think this would make it unusable (as App-Armour tends to be)... but it doesn't have to be that way. In fact, it's possible to make apps behave almost identically, as far as the user is concerned, without compromising anything.

I think we're still 10 years out before people wake up and realize that our collective assumptions about computer security are wrong, and this needs a more rigorous, carefully engineered solution, instead of the layers of patch we currently employ. I'm hoping that my frequent postings on this subject are informative, and help shorten that timespan significantly.

There are plenty of secure digital systems. Its not hard to make them, intact its quite easy. Trivial non networked systems are often secure. There is no need to go to analog, simple digital circuits are fine. I don't care how good your leet hacking skills are, I can make a single digital control system thats perfectly secure that sets line C high in line A and B are high. You can't hack an AND gate. There are plenty of places one can use provably correct digital control systems.

The idea is not that you need to put "Analog" in there somewhere, but rather that you should have simple things that are easy to secure, and design such that they are in the critical path for attacking. Ex: the Linux kernel is rather large (~15 million LOC). While its nice, you don't really want to rely on all that being secure. If you want security, you reduce the surface area exposed to attackers. If you are worried about incoming attacks over the network, air-gap = 0 area to attack. If you still need to allow come input, you can squeeze the threat through something simple which could be some analog mess as implied by the article, but more realistically would be a simple digital system, either hardware, or carefully validated (trivial) software, or both.

If you are willing to expose a bit more and get a real general purpose OS, you can opt for something like genode thats much more practical to design secure software for, and to validate the security of the OS itself.

TFA seems to be advocating using analog control systems to avoid things like cross site scripting attacks. Maybe drop the "site" and "scripting" before dropping the idea of digital control systems. If you don't care about putting your junk on the internet, and air gap will fix most of that crap, and if you do want it on the internet, too bad, IP is a digital protocol, and the analog version won't be able to work with it. Besides, those attacks are client side, so maybe just not exposing important infrastructure controls capable of wrecking everything if messed with to people using web browsers to edit them in a non-secure environment is enough.

http://genode.org/

Our biggest "cyber security" problem is one of persistently insecure endpoints. The reason we have persistently insecure endpoints is that they can't be made secure, no matter who writes them, checks programs for virii, etc

All of them run a program within the context of a users permissions, leading to the possibility of privilege escalation. SELinux tries to fight this by locking down each program, but even that approach has some strong limitations

To be able to securely run a program on any operating system, you need to be able to specify the side-effects you're willing to allow, before running the program. This is the reason that Functional Programming is getting so much attention and the application level.

The IBM VM system was among the first to provide such an environment, back in 1972. (I'm sure someone will dig up an earlier system). The reason that VM systems can be secure is that when you set up a virtual machine, you specify all the things it's allowed to use, and to change. It can only affect it's own disk space, etc.

Modern systems such as VMware also offer the possibility of real security, but at such a gross level of granularity that it's unlikely to be used in this manner. The only system on the horizon that offers a way out (as far as I can see) is the Genode project which is a full on capabilities based system, built upon your choice of secure kernel.

This whole cyber-war mess can be shut down, if you folks wake up, and start acting in a manner to fix things... otherwise prepare to be serfs to our corporate lords and masters.

Once Genode is done enough, we can start building secure systems that don't have the systemic weakness that comes from a default permissive paradigm.

Capability based security offers a way forward, up and out of this quagmire. We can just build systems that don't have holes, and eliminate cyber-war.

On top of using the archaic and slow Mach and having failed on attempts to move past that, HURD's an hybrid system, not a pure microkernel system. They're running their drivers in kernelspace.

Ironically, there's a free hybrid system much younger than the HURD which already has USB and AHCI: https://www.haiku-os.org/

To get a feel of how nasty Mach is, I recommend grabbing the slides from this talk:
https://archive.fosdem.org/2012/schedule/event/microkernel_overhead.html

Here's three actually free interesting microkernel and multiserver systems with a pure microkernel architecture (drivers are isolated) which are actively developed and have reached major milestones recently:
Genode: http://genode.org/
HelenOS: http://www.helenos.org/
Minix3: http://www.minix3.org/

Any of them three is more interesting than the HURD. Moreover, they mostly have support for AHCI and USB and run on more than just 32bit x86.

The root cause of our vulnerability isn't the users, nor the administrators, etc... it's the model underlying the OSs we all use. It trusts code, which is foolish at best.

To really fix computer security, you need to implement Capability Based Security. The Genode project is doing that, Here is their road map for 2013 which includes being able to eat their own dog food. (Which they wanted to get done by this year, but when has a software project actually met schedule?

If we can start to secure the nodes of the internet with non-swiss-cheese based OSs, we can just kill off this "cyberwar" nonsense once and for all.

If only there were a way to use a microkernel to run Linux.... ;-)