Tuesday, April 25, 2017

2nd CabSeec rant for the day...

Lots of things sucked back in the days of dual floppy drive PCs, but the one thing that was outstanding was the freedom with had, because our systems were secure. We could quickly make and test our own copy of the OS, and then write protect it.  We could also do this with our data.  Barring code that somehow bricked the system, we were free to try anything we wanted, without fear, because we had a transparent and effective way of limiting the scope of what a program did... even though we didn't see it as a feature at the time.

The ability to specify what files or folders a program should have access to (before or during runtime) is called Capability Based Security, or CabSec.   It's as simple as deciding what ingredients to put in a blender to make a smoothie.... you never have to worry that the blender is going to pick new things to add.

When you run a paint program the OS should provide a secure way for you to chose which files it allows the program to access... and CabSec systems do this in a manner works the same for the user, it's called a PowerBox.

Windows, Linux, Apple all fail to provide this one essential feature. This makes all of them completely unsuitable for a world of mobile code and persistent internet connectivity. Systems do exist at the periphery of the hacking world which offer hope, but they don't get much love. Genode and Hurd are at the top of my list these days.

The ability to limit the scope of change caused by a program is a fundamental part of mainframe operating systems... but its actually a side effect, and not a grand design feature.  VMware and other virtualization systems also serve as ersatz CabSec systems because the system requires the specification of virtual disks to be used to run a virtual machine... thus the changes can be limited in a manner similar to our old 2 floppy disk dos machines.

CabSec shifts the burden for limiting the side effects of code to the place it belongs... the operating system, It does this by never, ever trusting application code and instead allowing the user to chose the side effects to be allowed, at runtime in a clear transparent, and user friendly way.

CabSec brings back freedom.... we need to make it a reality... any help getting this concept pushed out into the mindspace of the programming community would be greatly appreciated.

Yet another rant about misplaced blame, this time problems with the Internet of (insecure) Things

People want to be able to put code in a box, and have code to function without unwanted side effects.

The consistent cognitive bias in the programming community is towards placing blame on certain groups or practices as being at fault, then piling on.

This approach consistently ignores the root cause, the lack of a widely used, secure operating system for anything smaller than an IBM mainframe.

If your OS can't be counted on to limit the side effects of a program to those chosen at runtime, you can't trust it.

Windows doesn't do this, nor does any other common operating system on PCs or embedded systems.

The reason mainframe systems are secure is that you specify the everything to be tossed into running a program prior to its execution, and it can't ever exceed those capabilities.

We need to make things GNU Hurd or Genode a viable choice for programmers and hackers, then for the average home user. If this is done, then we can finally actually fix things for once and for all.

Until then, IT is going to be a sump pump repair business, and IT Security is the roto-rooter man.