[cap-talk] "ACLs don't" paper rejected from Oakland 09

[Toby Murray]

On Tue, 2009-02-03 at 15:27 +0000, David-Sarah Hopwood wrote:
> Toby Murray wrote:
> > On Tue, 2009-02-03 at 14:03 +0000, David-Sarah Hopwood wrote:
> >> Toby Murray wrote:
> >>> In the ACL case, User's permissions are {Compiler.compile(x) | x denotes
> >>> any string}. In the capability case, User's permissions are
> >>> {Compiler.compile(Compiler)}. How do we know that these are, in fact,
> >>> different? We're not comparing apples with apples, since the text
> >>> strings have no meaning in the ACL case until interpreted by the
> >>> compiler.
> >>
> >> It doesn't matter how file designators are represented in the ACL system
> >> [2]. The point is that, regardless of their representation, there is no
> >> restriction on constructing and sending a message containing those
> >> designators.
> > 
> > Nor is there in a cap system.
> 
> There is clearly a restriction on which capabilities can be sent in a
> message: only those that the sender holds.

Sorry, I was confining my statement to messages that contain strings
only.

> 
> > I should have written that the User's
> > permissions in the cap system case are {Compiler.compile(Compiler)}
> > union X, where X denotes the User's permissions in the ACL case.
> 
> I don't understand this at all. If we limit consideration to meaningful
> 'compile' messages, then:

You're tilting the playing-field. What is meaningful to the Compiler has
no bearing on the User's permissions as defined by the access control
system, which is what we're comparing here.

> Since strings are not capabilities or vice-versa [*], these are not
> identical sets of messages (nor would they be isomorphic under the
> supposed equivalence), and so they are not the same permissions.

The lack of such an isomorphism is the basis for my original argument
that the two permission sets are incomparable and that one cannot say
whether they are equal or not.

> > In this sense, under your definition, User's permissions are greater in
> > the cap case than in the ACL case.
> 
> Mu. In the cap case, the User needs to send a capability in order for
> the attack to work, and is prevented from sending a capability that it
> does not hold. In the ACL case, the User does not need to send a capability
> for the attack to work.

But this doesn't change the fact that the user's permissions as far as
the access control system are concerned are greater in the Cap case than
in the ACL case, in that the latter are a subset of the former.

> 
> > It is the user's authority that is
> > greater in the ACL case, however, since being able to send strings to
> > the compiler does not increase the user's authority.
> 
> On the contrary, being able to send strings to the compiler (or more
> generally, being able to send any message to another subject) certainly
> does increase the User's authority, and its permissions.

I should have said "however, since being able to send strings to the
compiler in the capabilities case does not increase the user's
authority".

To summarise, in the ACL case, the user can invoke the Compiler, passing
any string. On this we agree.

In the cap case, the user can invoke the compiler, passing any message
they can construct which naturally includes any capabilities they have
access to as well as any string. Hence, the user's permissions here are
a superset of those in the ACL case. Therefore, the user's permissions
are greater here.

In the ACL case, the user can cause the compiler to write to the
logfile. In the ACL case it cannot. Hence it's authority is greater.

This does not pose a contradiction so long as you are willing to assess
permissions ignorant of subject behaviours. However authority cannot be
so assessed. 

If you include subject behaviours, then the user's permissions are
incomparable in both cases (because of the lack of an isomorphism from
strings to capabilities, as you pointed out) but their authority is
clearly greater in the ACL case.

Cheers

Toby