[cap-talk] Capability-based Projects - theory vs. practice

[Mark Miller]

On 8/3/07, David Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
> Mark Miller wrote:
> > A persistent E vat checkpoints some of its state to its checkpoint
> > file on the file system. Such a checkpoint file records the persistent
> > capabilities that its vat holds to objects in other vats as
> > cap-as-data URIs. So, inter-vat, E provides only cap-as-data security,
> > both for ephemeral caps and for persistent caps.
>
> That's not quite right. The programming model treats all capabilities,
> including cross-vat capabilities, as opaque. The implementation of that
> model uses caps-as-data, but the implementation cannot normally be
> accessed by an E program (assuming the program does not have authority
> to write [*] to the E implementation's private files, including the
> checkpoint file, or otherwise interfere with its low-level operation).
> So it is possible for an E program that spans multiple vats to be confined.
>
> [*] It does not matter whether the program can read these files, or
>     otherwise obtain the representation of a cap-as-data, provided that
>     it does not have authority (e.g. to the introducer) needed to convert
>     this representation to a live reference.

We're both right. Everything you say above does correctly describe the
potential behavior of objects within well-behaved vats that don't have
their vat's introducer authority, as you state. I was describing the
potential behavior of ill behaved vats, or of objects within well
behaved vats that do have this authority.

http://www.erights.org/elib/capability/dist-confine.html
but see
http://www.eros-os.org/pipermail/e-lang/1998-December/002314.html
(The Factory patent is now long expired, but E still has no support
for discretion, i.e., hole-relative assurance of confinement.)

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

    Cheers,
    --MarkM