[cap-talk] ACLs: why not have them IN ADDITION to capabilities

[Stiegler, Marc D]

There is a cornerstone to security, which security people invariably
discard as their first enthusiastic step when trying to achieve
security. That cornerstone is simplicity.

Having multiple security mechanisms is necessarily more complicated. It
makes life for the user more complicated, it makes life for the analyst
trying to figure out the real security claims more difficult. The only
participant who benefits from complexity is the attacker, who can
gleefully look in all the nooks and crannies hoping to find a place
where the multiple security systems didn't quite interlock correctly. A
terrific place to look for non-interlock is in those places where the
security overlaps so badly that the actual users trying to get some work
done will shut off one, or even beter, both, systems.

Hence multiple security mechanisms should only be invoked as a desperate
last resort. Sometimes such a desperate last resort is warranted. But I
haven't yet seen a payoff to adding an acl system that comes close to
warranting such an act of desperation. Your example below seems to be
addressed appropriately simply by using logging forwarders. Logging
forwarders don't tell you "who leaked", they tell you "who is
responsible for the leak", which is actually the more important question
to answer.

--marcs 

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of John Carlson
> Sent: Sunday, July 30, 2006 3:10 PM
> To: General discussions concerning capability systems.
> Subject: [cap-talk] ACLs: why not have them IN ADDITION to 
> capabilities
> 
> Much is said on this list about the "evils" of ACLs.  But why 
> can't we have them IN ADDITION to capabilities?  Do they break the
> capability model in some way?   What I am thinking the answer
> is that ACLs grant too much authority.  Is there some way to 
> fit ACLs into a capability framework (instead of vica versa). 
>  If you have somewhere in your system, a notion of user, then 
> you could write custom logic that would test for the user.  
> What I am thinking of is using client side certificates to 
> authenticate users.  The capability being passed to another 
> user *might* send with that capability  the user who was 
> originally granted the authority.  Then in some ways, we 
> could track where the capability travelled to (which we can 
> do anyway), and who was responsible for a capability leak.
> 
> This sounds like an administrative nightmare for most 
> systems, but adding the notion of user may help sell 
> capabilities in some circles.
> 
> John
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>