[cap-talk] an access control matrix model of capabilities

Zooko cap-talk@mail.eros-os.org
Tue, 01 Apr 2003 14:02:38 -0500


In this note, I describe a principle of access control: The Principle of 
Higher-Order Least-Privilege.  I argue that an "unextended" ACL system cannot 
conform to this principle.  I then describe a simplified access control model 
and make two modifications to it in order to implement Higher-Order 
Least-Privilege.  The end result is the capability access control system, as 
modelled by a two simple rules governing changes that can be made to an 
(extended) Lampson access control matrix.  My primary objective in posting this 
note to this list is to find out if this model is novel (not to mention to 
verify if it is correct).

[For those who don't want to read the model-building and rationale, you can skip 
down the "The Punchline", below.]


A salient feature of capability access control is that it can implement the 
"Principle of Higher-Order Least Privilege".  The (first-order) Principle of 
Least Privilege is that an object X should be able to use an object Y, while 
extending to Y only the minimal set of privileges necessary for Y to do its 
work.  This Principle can (at least in theory) be implemented by an ACL system.

The "Higher-Order Principle of Least Privilege" states that object X should be 
able to impose Least-Privilege constraints on object Y without X using any more 
than the minimal authority necessary to do so.

Only if an access control system supports Higher-Order Least-Privilege can an
object Y be simultaneously constrained (Y can have a subset of the authorities 
of its user X) and constraining -- a third object Z can have a subset of Y's 
privileges.

I will now take a simple access control matrix model and extend it in the 
attempt to achieve Higher-Order Least-Privilege.  I assert that the end result 
is the capability access control model.

The access control matrix consists of rows which are "subjects" -- things able 
to wield authority, and columns which are "resources" -- things to which we can 
control access.

In the first system, "S_0", there is a distinguished entity (the "admin") who is 
able to create new subjects.  Subjects can extend privileges that they own to 
other subjects, but they cannot create other subjects.  Subjects can also 
"switch" (setuid) to other subjects in order to execute code.  If a subject X 
wants to execute some code while allowing that code only a subset of X's 
privileges, X could extend a subset of X's privileges to another subject Y and 
then execute the code after setuid to Y.  However, X would have no way to 
guarantee that Y didn't hold other dangerous privileges.

As an example, X may hold the privilege to read a certain sensitive file and the 
privilege to send data to the network.  X may want to execute code with the 
former privilege but not the latter, in order to preserve the file's 
confidentiality.  X could extend the former privilege to a different subject Y, 
setuid to Y, and then execute the code, but X would have no guarantee the 
Y didn't have the "send to the network" privilege from a different source.  So 
X cannot safely enforce Least-Privilege on the code.

The only way to achieve Least-Privilege in model S_0 is for the admin to create 
a new subject T, grant to T the minimal necessary rights, take away all other 
rights from T, and enforce that T cannot receive any other rights while 
executing the code.  T cannot then extend a subset of those rights to another 
subject without also using the admin's powers.  Therefore, S_0 can implement 
Least-Privilege, but cannot implement Higher-Order Least-Privilege.  

We extend S_0 into S_1 by making it possible for ordinary subjects to create new 
subjects without recourse to "admin power".  A subject X can now create a 
subject T, extend a subset of X's rights to T, setuid to T, and execute the code.
T could in turn create another subject U, extend a subset to T's rights to U, 
and so forth.

Unfortunately S_1 still has the problem that T might gain privileges from 
another source.  X cannot grant T the privilege of reading the confidential file 
because X can't be sure that someone else won't grant T the privilege of sending 
data to the network.

The final change to the model then is to constrain which subjects can grant 
privileges to which other subjects.  We extend the Lampson access control matrix 
with a new column for each row.  This column represents the privilege of 
granting privileges to each individual subject.  In this new system, S_2, a 
subject X can grant privileges to a subject Y only if X has the privilege in 
question *and* has the "privilege to grant privileges to X".  When a new subject 
is created, only its creator has the privilege to grant privileges to it.  The 
"privilege-to-grant-privileges" can be granted just like other privileges.

S_2 implements the Higher-Order Principle of Least Privilege.  It is also 
identical to the capabilities system of access control.


The Punchline

In an ACL system, subject X can grant privilege P to subject Y only if X holds 
privilege P -- that is, only if X can access the P column of the (original) 
Lampson access control matrix.  In a capability system, subject X can grant 
privilege P to subject Y only if X holds privilege P and the privilege-to-
grant-privileges to Y -- that is, only if X can access both the P column and 
the Y row of the (original) Lampson access control matrix.


I would be very grateful to have your comments on this model and pointers to 
related work in the literature.

Regards,

Bryce "Zooko" Wilcox-O'Hearn

http://zooko.com/
         ^-- under re-construction: some new stuff, some broken links