Sunday, October 11, 2015

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.

No comments: