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

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Feb 3 09:27:01 CST 2009


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.

> 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:

 - in the ACL case, the User's relevant permissions are the permission
   to send {Compiler.compile(x) | x denotes any string}.

 - in the capability case, the User's relevant permissions are the
   permission to send {Compiler.compile(x) | x denotes any capability}.

   (If the system is typed, there may be additional restrictions on the
   type of x.)

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.

[*] A capability might be representable as a string in some systems, but
    if so, then the User will not know a valid representation of a write
    capability to the file 'log.txt' unless it is authorized to write to
    that file.

> 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.

> 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.

-- 
David-Sarah Hopwood ⚥



More information about the cap-talk mailing list