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

[Norman Hardy]

I think the short answer is that security stems from what you can't do.
If being on an access list is an additional reason that the kernel  
should allow an operation then we have broken all the capability  
advantages that I know.
Security arguments for the properties that only capabilities provide  
argue about reference graphs and that these are the only causal paths.
These arguments all break if you cannot say "These references are the  
only paths.".
I cannot confine if some access list, in a place that I cannot see,  
puts the 'confined' program on the list of programs that can write a  
file that I don't know about.


On Jul 30, 2006, at 3:10 PM, John Carlson wrote:

> 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