The .CABSEC fork in the road

Computer security is a mess, and to fix it, I believe that Linux, and indeed the entire open source stack, needs to get forked, I humbly suggest we call this the .CABSEC fork, so it is obvious to anyone who sees it what it is.

Cabsec (CApability Based SECurity) is a term coined by Doc Searls in response to a private email from me a long time ago when I asked him for advice about promoting the idea of capability based security. The problem is that the term capability has a bunch of meanings, most of which didn't fit my vision of the solution to computer security. Choosing a new term should help make things Google friendly... which made sense, so I've been trying to be consistent about using it every since.

I claim no special gifts for skills or wisdom, but rather I'm just a guy who has an idea which is self consistent, and seems to me (and to anyone I can talk to in person for long enough to explain it) to offer up a genuine solution to almost all of our computer security woes.... which I now call cabsec.

Cabsec is the embodiment of the principle of least privilege to be applied against the entire open source stack, if I can nudge things the right way. The core essence is to re-design things to flip the default assumption that programs can be made trustworthy, on its head, and go with the proven reality that this is false.

Not trusting your applications means you have to change things, mostly in terms of the user interface, the code that gets things done really doesn't need much work. Instead of asking the user to choose a file, then opening that file, you'd request the OS to do the same thing, and work with that handle (called a capability in cabsec).  

So you see, it really doesn't need to be a huge set of changes for any given program, but because of the scope (every program written!) it is a huge flipping piece of work to do.  I just want to introduce this simple naming convention to make it easier to coordinate... let's name all the forks .CABSEC forks.

Because of the way GIT works, it's possible to make a fork in a project, and keep it synchronized to take advantage of any changes that don't directly conflict with it in a low cost manner. This means that we could have the mainline stack keep going and feeding this new fork while everything gets done.

Overall, the plan would be to build a set of support APIs to do the required capability security calls on top of existing Linux in userland. This would allow testing and development of the concept to be done without any changes to the Linux kernel. If it turns out to actually work well, then we can push the changes into the kernel, or migrate to a different OS that supports native Cabsec.

I might be stupid, crazy, nuts, or right... only time will tell.  Thanks for your time and attention.

The root cause of our security woes

This is a cut/paste of a comment I posted to /.

The root cause of all of these security problems has been in plain sight since 1970 or so, yet only a few people are even aware of it. It's obvious once you get it, and the scope of fixing things comes clearly into place. So, do you really want to take on forking every program to build a new version of it? If so, you can fix it, if not... this will continue to happen, and government will try to fix it by fiat, badly.

The cause is that our operating systems operate on the assumption that programs can be trusted. This makes it almost impossible to launch an executable safely, because there is no OS enforced way to limit the side effects of execution.

Only an operating system that requires specifying the resources to feed to a given instance of execution can limit the side effects by design, instead of luck.

It doesn't have to be user-unfriendly, because the OS can always handle prompting for file names, etc... in fact if done properly, the user might not even need re-training to use the new fork of their favorite program, because for their intents and purposes, it acts the same, with the same dialog boxes, etc.

The principle of least privilege is the solution to this whole mess, but it has to be applied from the kernel all the way up the stack. This is a lot of forking work to do.

Do you dare to take up the challenge, or will you let someone else try the latest band-aid instead?