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

[David-Sarah Hopwood]

First a correction:

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

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

Toby Murray wrote:
> 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.

But that ignores the fact that in the cap system, the User needs to
send a capability, not a string.

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

Not really, just trying to simplify the discussion. In most systems
(either capability or ACL), the User could send many possible ill-formed
messages, but they are not relevant because they will be rejected by the
Compiler, or they will cause an error when the Compiler attempts to write
its output file.

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

In order to compare the systems constructively and fairly, we need to
compare the permissions to send messages that have corresponding meanings.
The capability system uses capabilities *instead of* string names, and
so if the cap system prevents the User from sending a message that means
"Compile putting the output in log.txt", while the ACL system allows it,
then the capability system has reduced the relevant permissions of the
User. It is a reduction in permission, not only in authority, because it
concerns only one subject's ability to directly perform one operation.

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

I don't think this argument makes sense. Suppose that one system happened
to support a decimal floating-point type, and the other system didn't.
Would the permissions in the former system be greater just because it
could send decimal floating-point values (even when comparing messages
in which such a value had no defined meaning)? Of course not.

It is the sets of possible meanings of messages that should be used in
the comparison, not the sets of possible values.

In any case, if the permissions are merely different, which we seem to
agree on, then there is no equivalence between the systems with respect
to instantaneous permissions. That is, the equivalence claim is wrong
even ignoring dynamic behaviour.

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

Right; we don't disagree on that. (More precisely, it is greater in
examples where the Compiler had permission to the output file
already, and didn't need that permission to be delegated to it.)

-- 
David-Sarah Hopwood ⚥