[cap-talk] Announcing "Analysing Object-Capability Security" Paper and Authodox v. 0.2.0

[Mark Miller]

On Wed, May 28, 2008 at 12:15 PM, Toby Murray
<toby.murray at comlab.ox.ac.uk> wrote:
>> TheRevocableFwdr presumably could have been given a read capability
>> direct to Fred, making this a diagram of one pattern rather than two.
>
> That's just the point. In the object-capability model, one cannot create
> a "read"-only capability to Fred. One instead needs to construct a proxy
> that forwards only "read" messages to Fred. TheReadOnlyFwdr is just such
> a proxy and its job is to mimic a "read"-only capability to Fred.
>
> Of course, in many real capability systems, one can create "read"-only
> capabilities to files, particularly OCap operating systems. However, the
> same is not true for OCap languages, like E and Caja. The
> object-capability model must be generic enough to accommodate both
> styles. Since one cam mimic the OS style by using proxies, the
> object-capability model chooses to adopt that approach to make it
> compatible with both kinds of system (i.e. to allow it to be used to
> model both kinds of system).
>
> [The OCap model is totally Mark Miller's creation, btw. Hopefully he'll
> chime in if I've messed up any of the above.]


Exactly correct, though it can be either an externally-provided
attenuating forwarder (or proxy) as in your example, or a forseen
facet that operates directly on the shared state. The relevant text
from section 8.1 of my thesis is:

By _object_, we mean the finest-grain unit to which separate direct
access rights may be
provided, such as a file, a memory page, or another subject, depending
on the system.
Without loss of generality, we model restricted access to an object,
such as read-only access
to /etc/passwd, as simple access to another object whose behavior
embodies the restriction,
such as access to the read-only facet of /etc/passwd which responds
only to queries.


-- 
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM