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

David Hopwood david.hopwood at industrial-designers.co.uk
Fri Aug 3 12:52:12 EDT 2007


Mark Miller wrote:
> 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.

Right, but if two vats are provided by the same E implementation, then
the integrity of the implementation is the same for both vats. So it
would be more precise to say:

  Inter-(E virtual machine), E provides only cap-as-data security, both
  for ephemeral caps and for persistent caps.

(Confinement is not possible for a subsystem that has the introducer
authority, even within a single vat.)

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

Surely the auditing framework is already sufficiently expressive to
write such an auditor? It would be very similar to the auditor for
DeepFrozen, but would be parameterized by a set of holes that it
would also accept.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>



More information about the cap-talk mailing list