[cap-talk] Capabilities - the rub, an account

Valerio Bellizzomi devbox at selnet.org
Sun Nov 26 19:46:39 CST 2006


On 26/11/2006, at 13.02, Jed at Webstart wrote:

>At 05:14 AM 11/24/2006, Marcus Brinkmann wrote:
>>On Fri, 2006-11-24 at 16:17 +0800, John McCabe-Dansted wrote:
>>...
>>Capability systems usually solve this issue by foregoing the goal of
>>collecting and maintaining global information about what's going on in
>>the system.  I agree with your finer point that at some level you want
>>to re-establish such information at least at an intermediate level, for
>>example user-to-user interaction.
>
>I believe this is where I've been trying to take this thread.
>
>>I think that this makes sense, and it is one reason why I consider
>>revocable copies an essential feature in capability systems.
>>Unfortunately, building a system that has unlimited (by the system)
>>nesting of capability wrappers and no denial-of-service threat scenario
>>is a big challenge (see the current L4 redesign efforts with
>>user-managed kernel memory).
>
>I don't think such an implementation is as difficult as it might seem,
>particularly if the protocol for communicating permission goes through
>the server of the 'object'.  In that case what you consider a "big
>challenge"
>I believe becomes rather simple book keeping.
>
>>In general one would want to reduce the role of the system administrator
>>and the system software in general in a modern operating system.  The
>>Unix model of root on the one side and the users on the other side has
>>great disadvantages, both in terms of security and in terms of
>>functionality.
>
>I agree, though I go further to say that the whole Mandatory Access
>Control model is broken and even the discretional access control
>mechanisms designed to that philosophy (as in Unix) are so
>unwieldy as to really deserve Lampson's castigation, for example
>(stealing his words, something like):
>
><humor>
>ACLs have done an enormous amount of damage to security because
>they require you to do all your access delegations through a systems
>administrator.  There is so much overhead in doing so, that, even if
>you get right today it will be wrong three months from now.  Nobody will
>have the patience to ever look at it again because there is just too
>much overhead going through the systems administrator for every
>change.  So I say absolutely no to administrator controlled ACLs.
>Everything should be as automated and as fine grained (O-O) as
>possible so that people generally don't have to deal with delegations.
>That's a very unpopular position with most people.  I think there's a lot
>of empirical evidence that tells us now that it's right.
></humor>

In other words, the ACL model is too much coarse-grained to allow careful
detailed configuration of permissions.

val

>
>--Jed http://www.webstart.com/jed/ 
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk





More information about the cap-talk mailing list