[cap-talk] membrane implementations?

[Marcus Brinkmann]

Hi,

when capabilities can be fetched through other capabilities, ie as
return parameters in interfaces implemented by the capability object
referenced by the capability, selective revocation by means of a
wrapper object may be insufficient: It may be that the provider of the
wrapper object desires that all permissions derived directly from the
capability object should be revoked with the capability to the object
from which they were derived, transitively.  It is my understanding
that an object which is supposed to achieve this outcome has been
called a membrane here on the list recently.

I want to have a closer look at what support is required from the
capability-object system to support such membranes.  I will start with
the simplest model and add features and alternative features along.
It seems to me that membranes require sophisticated support from the
capability-object model to be feasible, or their application must be
restricted to a few narrow cases.  But I may be missing something.

Clearly selective revocation is necessary, which can be done by means
of an interposed proxy object.  The proxy object has to create new
proxy objects for each incoming capability, or at the very least for
each incoming capability object.  If it can proof that two incoming
capabilities are equal, then it can reuse a wrapper object for that
capability.  To do this efficiently requires more than an equal?
operation: It requires a CapLookup operation that can efficiently find
capabilities that are identical to a given one if they exist.  For
example, in Mach all capabilities ("port names") are translated on IPC
to references for the same local name, and equality reduces to an
integer comparison.  In this example, a hash table can be used to
locate reusable wrapper objects.  In the absence of such an locating
operation, with only equal?, reusing wrapper objects requires a linear
search and may be prohibitive.

Even with reusing wrappers in this way, the number of incoming
capabilities is potentially unbounded as old objects get destroyed and
new ones are created in the system.  Thus the second issue that comes
to my mind is the question of reclaiming wrapper objects which have
become stale because the wrapped client dropped the capability.  In
the absence of a way to notice capability drop events, any wrapper
object once created must be kept alive indefinitely.  The normal
application for membranes are wrapping untrusted clients: thus I will
not consider cooperative protocols here, but one should note that a
cooperative protocol would break the abstraction that the wrapped
capabilities should be treated like normal capabilities, except for
their limited durability.  To use Mach again as an example, Mach could
send "no-senders" notifications if all extinct capabilities to an
object were destroyed.  This was a global monitor on all capability
spaces in the system.  A compromise would be to weaken to monitor to
only consider the cap space of the wrapped client, but this means that
the capability abstraction is broken.

The problem here is that a membrane is double-blind: It is not
notified eagerly if a wrapped capability becomes invalid, and it is
not notified if a wrapper capability is dropped.  The resources
consumed in the membrane seem not to be limited by either the
capability objects in the system nor the capabilities hold by the
client.  In the face of this situation, I do not see how an enforcable
defensive membrane can be implemented without sophisticated support in
the capability-object system itself.

I would like to know how other systems faced this issue, if they did
at all, and how you would address it if it were to become your problem
:)

Thanks,
Marcus