[cap-talk] automatic policy embodiment and enforcement - hope ?

[Karp, Alan]

David Wagner wrote:
> 
> Certainly what you write is not my understanding.  From talking to
> old-timers in the security community, the consensus (at least inside
> the security community) seems to be that capabilities were tried, they
> allowed more fine-grained access control, but this finer granularity
> was too hard to manage.  As I've heard others describe it, the feeling
> seems to be that any other method of fine-grained access control would
> probably have had similar advantages and disadvantages.
> 

I've thought about this issue a bit.  I've concluded that managing a system supporting explicit authorities only appears more complex because we don't factor in the overhead of securing the ambient authority system.  CapDesk has shown that the vast majority of the security decisions in an explicit authority system, such as one based on capabilities, can be inferred from explicit user actions.  Only a few of these decisions need additional information from the user.  

Contrast the simplicity of CapDesk with the difficulties of securing an ambient authority system.  There are many things you can't do.  You can't run macros, you can't launch email attachments, and you can't enable scripting on web pages because they might abuse your authorities.  There are numerous dialog boxes asking the user to make security decisions with no basis on which base a decision.  We must run virus scanners, and frequently update signature files, and still viruses get past the scanners.  Digital certificates are used to establish trust when most people have no idea of the implications associated with their use.

Even Ross Anderson's economic analysis favors object capabilities.  In an ambient authority system, the attacker needs to find only one exploitable flaw to gain all the user's authorities.  In an object capability system, the attacker must find a combination of flaws in a number of objects in order to collect enough authority to do substantial harm.

I like to think of it this way.  An ambient authority system forces us to ask "How can we prevent attacks from succeeding?"  In an explicit authority system, the natural question is "How can we limit the damage that can be done when an attack succeeds?"  I contend that the former question is a good one to ask, but a strategy based on it succeeds only when we achieve perfection.  A strategy based on the latter question is one we'll need to answer until we've reached that state of grace.

>                                        
> One could hypothesize that the cost
> of programming with capabilities will be only slightly larger than the
> cost of programming without capabilities and without concern 
> for security.

The key phrase here is "without concern for security".  That's not fair, but even so the case for object capabilities is favorable.  MarkM has quantified this cost with Joe-E, Java + Elib.  Don't use static methods or global mutable state.  Just do that much and you'll get most of the security benefits of object capabilities.  As an added bonus, this restriction is good coding practice anyway, making the code more maintainable.

> 
> Well, I can fix that.  There are plenty of counterexamples.  Systrace,
> SELinux, and Janus all provide "privilege reduction" on a per-process
> basis. 

You are still left with an ambient authority system.  Even worse, it's a static system.  There's no convenient mechanism for adding additional authorities or revoking those that were granted.  Because of this, such systems still grant far more authority than dictated by POLA.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp.vcf
Type: application/octet-stream
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20040922/0a53f294/AlanHKarp.obj