Sunday, October 11, 2015
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.
Saturday, June 16, 2012
It builds on the work of L4 and all the other microkernels, providing a way to run on 8 different microkernels in total.
I'll do what I can to help push this along. I'm sorry it took so long to find... Google isn't the great way to search, but it's the best so far.
Saturday, May 26, 2012
Saturday, November 5, 2011
Eric Drexler asks some interesting questions, and has points for discussion... here are my answers.
1. Because traditionally the user was (or knew, worked with, etc) the programmer, and was assumed to know what he was doing.
2. In the past, the odds of a rogue program were almost exactly zero, so using administrative time and effort to further segregate things would have been wasted.
3. The system calls supplied in Linux, Windows, etc... are not geared towards it, so it is not natural, nor easy to grant limited capabilities to a program.
Virtualization, and the rise of VMware and it's competitors are a direct result of the lack of the capabilities model in contemporary operating systems. In such an environment, the program (a virtual machine) is given specific access to a set of resources at run time.
4. Capability BAsed SECurity, (Cabsec for short) is the model of choice. I've tagged some entries at delicio.us with cabsec, you can review them here:
I'm interested in helping out if you're gearing up for a project.
Thought and discussion -
1. It does it this way because historically the user and programmer were the same person, or at least in the same organization. It made sense to give each group a sandbox, and permissions to read a common set of tools. All of this was determined by system administrators. The groups then managed their own affairs within their sandbox.
Needless to say, that model is insane to use in an era of modern code.
2. The cost is refactoring programs to accomodate a new security paradigm, where resources are supplied to a program, instead of just grabbed ad hoc.
The benefit is that the user would have explicit control over the resources given to a program, which can prevent a large class of security problems.
If widely adopted, it would make the internet more secure by decreasing the population of hosts which can be compromised and exploited.
3. There are no widely used capability based operating systems that I'm aware of at this time. There are features of things that are like capabilities, which should be promoted as such, to help popularize the model and move it into the realm of toolsets people consider using.
Tuesday, December 21, 2010
Friday, April 16, 2010
Tuesday, March 16, 2010
Wednesday, March 3, 2010
So, the Obama administration has declassified part of the "cybersecurity" planning of the Bush administration.... the story hit slashdot, and here's my response.
I propose instead that we consult the results of the previous R&D work that has been active in this area since the 1960s, and learn the lessons of problems already solved. This is low risk (as we've already paid for it), high payoff.
Let's get capability based security into the hands of the masses. This will remove their machines from the threat pool. It would also allow those inside the government to manage security in a much more granular (and thus more effective) manner.
This can be fixed, and it doesn't require a high risk, just due diligence, and hard work.
Monday, January 4, 2010
It's not the Internet switching fabric that is the problem, it's the end nodes. None of our PCs is provably secure. It's highly likely it won't be by 2020 either, as it appears the money is going into the wrong places in research. Capability Based Security has been around since the 1980s, and yet it's not even being funded to try to get it ready for widespread use by 2020.Until the ends of the internet are secure, it's not going to be secure. It almost seems the money is always being spent in places where it won't really help the end user, but will allow more control by the authorities. (Or maybe I'm just a bit paranoid?)
Capability Based Security hinges on the operating system being inviolate. The problem is programmable computers by their very nature offer the opportunity to reprogram the whole system. This is not a bad thing, because it allows the same device to be used in various different ways (Linux, Windows, OSX etc) - diving deeper, it allows more efficient software (patches) to be added to the system by anyone with the desire to accomplish some task, or make the system run more efficiently.With a capability based security system in place, OSs would collapse into one 'approved' version - and the general purpose nature of the computer would be lost (a game console would be the current model for such a system I would think).
Actually, it's not the whole system that has to be inviolate, just the kernel. There are projects to produce a provable L4 microkernel, for example. This would allow the user to have a machine that they could then trust to only give away resources they chose.Don't confuse a locked down kernel with a locked down computer. With the current OS selections you have, it's not possible to make a distiction, but it doesn't have to be this way. The problem boils down to the default permissive environment that we're all used to thinking and modeling our systems on top of. Capability based systems are a default deny environment, but you are free to give away as much as you want to a program of your choice.
Thursday, December 3, 2009
Tuesday, December 1, 2009
Sunday, November 29, 2009
Wednesday, April 29, 2009
The most serious reliability and security problems are those relating to the operating system. The core problem is that no current system obeys the POLA: the Principle Of Least Authority. The POLA states that a system should be partitioned into components in such a way that an inevitable bug in one component cannot propagate into another component and do damage there. Each component should be given only the authority it needs to do its own job and no more. In particular, it should not be able to read or write data belonging to another component, read any part of the computer’s memory other than its own address space, execute sensitive instructions it has no business executing, touch I/O devices it should not touch, and so on. Current operating systems violate this principle completely, resulting in the reliability and security problems mentioned above.
Thursday, May 22, 2008
Ambient Authority - google search
Here's a nice post that summarizes a lot of what Capabilities is all about from Julien Couvreur.
Tuesday, May 20, 2008
As an educational resource it's pretty good so far.
Update 5/22/2008 - It was VERY useful, and I learned some new terms, like Ambient Authority, and got some new examples to use.
Saturday, May 17, 2008
Tony Jones while giving an overview of AppArmor to the Linux Kernel Mailing List said:
Now, this isn't a true capabilities system in that the profiles use names, and are explicit, but it does help enforce least privilege, so it's a very strong step in the right direction.AppArmor is *not* intended to protect every aspect of the system from
every other aspect of the system: the intended usage is that only a
small fraction of all programs on a Linux system will have AppArmor
profiles. Rather, AppArmor is intended to protect the system against a
It allows the Administrator to give rights to run some things, without handing over the administrative password.
The interesting thing about this is that they mention capabilities in their security model, and they offer support for pluggable security modules. So, even if they don't due "pure" capabilities, someone else could add a library that does.
Friday, May 16, 2008
I wish Blogger's moderate comments system was smart enough to whitelist people. I hate having to reapprove legit users over and over again.
Now, this is a call for capabilities if I've ever seen one. He wants to be able to delegate a capability to someone.
Ok, this one creeps me out a bit... they really, REALLY, REALLY want to make sure the user who is connected to whatever little box really is who they say they are. This project seems to want to build the backend to the REAL ID act of 2005.
Aside from my personal aversion, they are a STRONG IDENTITY project. You would have one set of keys to the kingdom, that would open everything. One ring to rule them all.
I don't understand the rest of it, for now, it's way over my head. I now understand a bit more about the ACL vs Capabilities history, and that's enough for me.
An open protocol to allow secure API authentication in a simple and standard method from desktop and web applications.
OAuth is a limited implementation of capabilities. A token allows proxy access to a resource on the internet. This eliminates the need to share authetication information.
They do a lot of great things. Their home page is clean and simple. They have example code in many programming languages. They have a FAQ section, chat and a wiki.
I'm spending time and innumerable frustrating searches on this topic. Capability based security is not even close to Google friendly. Because there isn't a specific set of buzzwords to describe the concepts involved, the terms that do get used are sufficiently common that most searches get a ton of noise. I've spent a lot of time finding things of interest, so I'm sharing what I find on this topic, in this one space.
I'll keep original articles and other thoughts at my regular blog, and occasionally link back to it.
I'll also be pointing out things that are related, but near misses.
For example, I came across OAuth, which is about delegating access to Internet accessible resources without the need to share authentication information in a standard way. It's a good step in the overall evolution of security, but is not capabilities oriented.
I'll also be using Labels (tags) on the posts, with Hit or Miss to indicate if a given post is about a find that is or is not truly capabilities based.
In summary... I'm setting myself up as a gatekeeper to judge what is/isn't capabilities.