Saturday, November 5, 2011

Eric Drexler asks some interesting questions, and has points for discussion... here are my answers.

Quiz -
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 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.

No comments: