[cap-talk] membrane challenge - an Attack!

David Wagner daw at cs.berkeley.edu
Tue Nov 16 22:35:44 EST 2004

Jed writes:
>I'll be interested to hear what people think of this

It's not a problem in the E language per se.  It's a flaw in the services
that you've implemented on top of E: those services do not enforce the
security property they were intended to.  It is a fact of life that one
can build an insecure service in any language -- if the service is given
some authority to manage, and the service fails to control access to that
authority properly (where here "properly" is defined by the application
goals of the service), then you lose.  What language-based security tries
to promise is that a buggy service cannot harm anything other than the
authorities it is legitimately given -- but we cannot prevent it from
harming the authorities it has been entrusted with.

If both the SN service and the membrance service were part of the default
E runtime, then it would count as a flaw in the E runtime.  (I don't know
whether they are included in the E runtime, accessible to E code, or not.)

The problem arises from the composition of the membrane server and the SN
("hat check") server.  Those two, at least in the form you have described
them, don't compose.  If you want membranes, you can't have a SN server;
if you want a SN server, you can't support membranes securely (at least,
not if they are implemented in the way you describe).  If you want to
have both a membrane server and a SN server, you have to implement them
differently, so that one of these servers is aware of the other.

It's not unusual to find two services that are each secure on their
own, but become insecure when composed.  In this case, server S1 (the SN
server) is able to enforce property P1 (limits on who can get a capability
from S1) when it makes certain assumptions about its environment; server
S2 (the membrane server) is able to enforce property P2 (all capability
transfers between Alice and Bob are mediated) under certain assumptions
about its environment (e.g., that no part of the environment provides
some other communication channel between Alice and Bob that bypasses the
membrane and allows to convey capabilities); yet a system that contains
both S1 and S2 cannot enforce both P1 and P2.  The resolution of this
paradox is that S1 violates some of the assumptions S2 makes about its
environment: the SN server provides a channel that allows Alice and Bob
to communicate capabilities between each other, even though Alice and
Bob are separated by a membrane.  Assumptions made about the environment
are often hard to identify in advance, so this kind of composition flaw
is not unusual.  It's sometimes known as "the composition problem".

If you want a membrane server and a SN server to co-exist, then
the SN server will probably need to be aware of the membrane server.
For instance, the SN server might provide separate Swiss Number namespaces
for each domain that is intended to be separated by the membrane server.

Note that there are other potential implications of running a SN server
(e.g., capability confinement becomes as hard as bit confinement).

At least, that's my reaction.  My understanding of membranes is rather
superficial, so I hope I haven't gone astray.

More information about the cap-talk mailing list