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

[Jed at Webstart]

At 01:34 PM 7/31/2006, Norman Hardy wrote:
>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.

I suspect John is suggesting the flip side of this choice, namely that
access requires both a capability and being on an ACL.

To me this model is equally broken.  Suppose I'm a process that wants
to delegate access to some object that I can access to some other
code in a POLA manner.  How do I do such delegation?

Can I send a capability in a message requesting the service I need?
If so, how do I then get the process (active object) that will implement
the service on the needed ACL?

This first brings up the question of just what sorts of subjects are
on ACLs.  In most ACL systems it's people (users, principals, etc.).
This is of course broken because it's back to a form of ambient
authority.  Is it then processes or addresses that are the subject
side of the ACLs?  If addresses then one can use an ACL mechanism
to implement capabilities - a bit awkwardly.  Both the DCCS:

http://www.webstart.com/jed/papers/DCCS/

and the ACL mechanism in:

http://www.webstart.com/jed/papers/Managing-Domains/#s10

use an ACL implementation for communicating capabilities.  That is
access to an object is the unit of communication (designation
and permission) and it is merely an ACL implementation (e.g. to
avoid using encryption on a network) that is used behind the scenes.

The other question is regarding what grants permission to modify the
ACL for an object?  If it's the mere possession of a permission that
grants the right to add that permission to another process/active object,
then you have essentially an implementation of a capability mechanism.
If it's something else, then what?  In that case of something else things
can get very confused.  There are cases, for example, where a user
or process may not have a permission itself but may have the permission
to grant a permission to another user or process - not themselves.

You can do things like that, but to what end?  What value does an
ACL system (much less an additional ACL system) provide?

I believe the putative value that ACL systems provide and why people
hang onto them so tenaciously is that they seem to allow one to look
at something - namely the ACL - and see what subjects have access
to an object.  This has a certain appeal.

But now consider - if one wants to do POLA to the process level, what shows
up on the ACL?  Some process ID or network address?  How useful is that?
Even if you find some potential value to being able to look at process IDs
(or even usernames at that level) on an ACL, you can only depend
on it to the extent that permission can't be delegated - as we know it
can be by proxy where communication is possible.

To my thinking its just a broken concept that doesn't work in practice.
The real difficulty with ACLs comes down to practical issues like how
to set the ACLs - e.g. see why so few people can derive any value out
of the SELinux extensions with ACLs.

I do know of one place where an ACL mechanism seems to be working
fairly practically.  Namely in access control for LDAP servers.  There
one grants users (as authenticated to the server) access to parts of
the directory structure based on who they are, e.g.:

access to dn.subtree="ou=people,o=ldapsvc,dc=nersc,dc=gov" attrs=userPassword
         by self read
         by dn.base="cn=Manager,dc=nersc,dc=gov" write
         by dn.base="cn=Replicator,dc=nersc,dc=gov" write

The above is allowing users to read their own passwords (the hashes actually)
for authentication, and granting two users, the "Manager" and a "Replicator"
user write access to the passwords (on a replicated server).

Lacking any sort of capability mechanism, the above use of an ACL seems
quite reasonable to me.  Of course a mechanism like the above is managed
by a system administrator (e.g. like me) where what is effectively "root"
access grants the authority to modify the ACLs.  This approach isn't suitable
for sharing between users, between processes, across a network, etc.

--Jed http://www.webstart.com/jed/