[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Fri, 2007-07-13 at 11:08 +1000, James A. Donald wrote:
> A capability in this sense is a communicable permission...
> At the
> implementation level, the permission may be implemented
> as a value in a sparsely populated address space that
> enables access to an event queue through a filter...

That can be read a couple of ways. If what you mean is that a capability
can be expressed as an unprotected data value that is protected by
sparsity, then I think this is wrong. The result is not a "protected
capability system", and necessarily suffers from all of the deficiencies
identified by Boebert, Gligor, etc.

Conversely, if the capability itself is protected, it is not clear what
purpose is served by introducing sparsity.

> We want communicable permissions so that more trusted
> code can issue permissions to less trusted code.

Yes. We also want to be able to communicate permissions between
"lateral" or co-equal trust relationships.

> Thus the edit program does not need and should not have
> a general ambient capability to open any file it
> pleases...

This is problematic. I agree with what you are trying to say from a
security perspective. The problem is that *shells* really *do* require
the ability to do that, and users have been trained into the belief that
just about any application should be a shell. This is particularly
apparent when one considers emacs, but as a second example consider the
ubiquity of the File menu.

> , so cannot be a trojan horse

There are many types of Trojan Horses. An editor lacking general read or
create authority can still corrupt or exfiltrate data when it is
encountered. This would definitely be considered a Trojan Horse.

> , nor can bugs in
> the edit program be exploited by a virus or worm.

Depends on whether we consider the covert exfiltration code to be a bug.


Please don't misunderstand me. I agree that the structure you are
proposing is a great improvement, and I agree that it is mostly
feasible. Better still, I even think that OpenOffice and Firefox could
be re-engineered to implement it.

I just want us to be careful not to make inaccurate statements as we try
to pitch this stuff.

> Horton is unlikely to get this category of government
> employee on side.  With Horton, instead of having
> authority to give or deny people permission to do things
> that they need to do, they would be discovering who had
> done something bad - and reporting that to people in

This last comment (and much of what preceded it) is a very cogent point.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC