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

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Feb 3 08:03:17 CST 2009

Toby Murray wrote:
> On Mon, 2009-02-02 at 17:05 +0000, David-Sarah Hopwood wrote:
>>> Note that the different "outputs" here are authority not permission.
>> No. As the paper says for the example of section 2.3,
>> # In capability transfer, the User's attempt to construct a compile message
>> # specifying write permission to log.txt is rejected by the reference
>> # monitor [...]
>> Sending the compile message is an individual operation that the ACL system
>> allows (because "log.txt" is just a string in that case), and the capability
>> system does not (because log.txt has to be specified by a write capability),
>> in the same access matrix state.
>> That is, the capability system is performing an access check, based on the
>> direct permissions of the User at the time of the message send, that is not
>> performed for the equivalent operation

[I meant "corresponding operation".]

>> in the ACL system. There is no sense in which they can be construed as
>> equivalent.
> We're using different definitions of permission. I'm using permission as
> "the ability to directly perform an operation on another party". You're
> using it as "ability to directly perform an operation on another party
> passing specific parameters."

I don't understand your point. The operation in this case is sending a
given message.

If access checks were not able to depend on the parameters to an operation,
then there would be no way at all to model what the capability system is
doing (or what other kinds of protection system are doing in many other
cases, for that matter).

The capability system does restrict the parameters to a message send [1],
and the ACL system doesn't. If this is not a difference in permission,
then what is it?

[1] Actually by only allowing valid capabilities to be represented rather
    than by performing an explicit access check, in most capability
    systems, but that's a minor point.

> Under my definition, the user's permissions in both cases are:
> {Compiler}, the compiler's permissions in both cases are {Logfile}.
> Hence, under this definition, there is no difference in permissions.
> 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. In the capability system, the designators have to specify
capabilities (otherwise the Compiler would not be able to access the file),
and the User has to hold each specified capability.

[2] For this discussion we are ignoring any capability-like features
    of real ACL systems, and so we're assuming that capability-like
    designators such as file handles are not passed between subjects.

> Hence, I'd argue that one cannot make an inequivalence claim
> on this evidence alone. It is the difference in the User's authority
> that can be compared between the two cases and it must be this difference
> on which an inequivalence is judged.

The distinction between permission and authority is defined in MarkM's
thesis, section 8.1:

# When discussing any access control model, we must carefully distinguish
# between /permission/ and /authority/. Our distinction between these is
# adapted from Bishop and Snyders distinction between de jure and de facto
# information transfer [BS79]. However, we are concerned here with leakage
# of access rights rather than leakage of information.
# A direct access right to an object gives a subject the permission to
# invoke the behavior of that object [Lam74]. In Figure 8.1 Alice has
# direct access to /etc/passwd, so she has permission to invoke any of
# its operations. She accesses the object, invoking its write() operation.
# Alice can directly write /etc/passwd by calling write() when the system's
# protection state says she has adequate permission. In Figure 8.2, Bob,
# who does not have permission, can indirectly write /etc/passwd so long
# as Alice writes there any text Bob requests her to.
# When Alice and Bob arrange this relying only on the "legal" overt rules
# of the system, we say Alice is providing Bob with an indirect access
# right to write /etc/passwd, that she is acting as his proxy, and that
# Bob thereby has authority to write it.

In the case under discussion, we are talking about the ability to send
a single message. There is no indirection, and whether the operation is
allows depends only on the protection state associated with one subject.

David-Sarah Hopwood ⚥

More information about the cap-talk mailing list