[cap-talk] membrane challenge - an Attack! - discussion

[Jed at Webstart]

At 11:27 AM 11/17/2004, Bill Frantz wrote:
>There are a number of reasons we should proceed with caution when making
>statements about membranes:
>
>* As far as I know, there are no real, time-tested examples of the
>membrane pattern.  In addition, there is no theoretical base for them.
>As such, we don't really know what they can and can't do.
>
>* As far as I know, this group is the first to try to reason about
>authority, as compared with permission.  Again, I don't think we have
>either strong intuitions or theory to guide us.
>
>
>The KeyKOS MLS design used a form of membrane to separate the
>compartments.  This membrane was the interface between a single-level
>compartment, and the larger system directory.  It examined the
>capabilities passing over the interface and only permitted them to pass
>if: (1) The MLS labels on the objects permitted the transfer, and (2)
>the objects were manifestly sensory[1].I don't think any of the
>discussion of membrane function effects a membrane with these
>specifications.

I don't agree.  The point of the example attack is that if rights (what
I refer to as capabilities as distinct from any particular representation
of capabilities on a system) are communicated outside the assumed
model (representation) of capabilities on a given system then they
will pass right through any membrane - regardless of what sorts of
properties it is looking for in the objects.

>The membranes we are discussing are much more complex membranes, and we
>aren't being clear about their specifications.  For example, MarkM
>contends that allowing a time-limiting membrane to manipulate
>capabilities which aren't time-limited is broken.  If this is a design
>principle, then we also must examine any time-limited object which
>allows a change in authority.  A Unix style directory that permitted
>"mv" to change authority would be an example.
>
>On the other hand, Jed thinks that the effects of manipulations through
>time-limited membranes should persist after those membranes are
>destroyed.  We need to think clearly about just what these membranes are
>supposed to do.

I think I must be a bit confused here.  My understanding is that the
whole purpose of the membrane was to transform capabilities (rights)
from a time-unlimited (or at least not limited by the membrane) form
to a time-limited form - specifically a form that can be revoked
exactly when the user (Alice in this case) decides to pull the
plug on the membrane.

If that's the case then saying that it's "broken" to allow a time-limiting
membrane to manipulate capabilities which aren't time-limited doesn't
seem to make any sense.  Of course there's nothing to say that
Foo couldn't have actually been some sort of time-limited right
I'm generally quite suspicious of such "time limited" rights in general
as so often they seem to be surrogates for not really solving the
protection problem and just arguing that "It's OK" because the
rights will all go away eventually.  The point of the exercise is
that even if Foo were time-limited its right would not be revoked
from Bob when the plug was pulled on the membrane.

>Some questions to ask are:
>
>* Is keeping the E language "makeSturdyRef" function inaccessible
>through membranes sufficient to keep the CapTP system from leaking
>time-unlimited authority around a time-limiting membrane?

Of course my point with the attack was to illustrate how rights can
be communicated through a membrane without its knowledge by
using a different form or right (=capability in my book, but not faithful
to the systems - e.g. E's - representation).

>* What kind of objects and structures of objects does it make sense to
>use with time-limiting membranes?

I argue it must be all or none.  In general how does Alice know what
sorts of objects she might be indirectly passing to Bob?  The capabilities
might themselves be proxied or implemented by a server that Alice
doesn't understand.  Surely Alice can't be required to know all about
the rights that she is communicating via the membrane to Bob.

A minor variation on the attack I posed could have the object passed
to Bob through the membrane be a single directory capability that
contains the rights Foo and SN.  Of course such rights could be
anywhere up the directory chain or indeed only available through the
object passed through means not known to Alice.

Alice is only communicating to Bob because there's something she
need to have Bob do for her.  She is using the membrane mechanism
because she wishes to be able to revoke not only the capabilities that
she sends to Bob but any Bob is able to fetch through those that
she sends to him.  She does this precisely because she doesn't
know what sorts of capabilities (rights) are available subsidiary to
the direct capabilities that she passes to Bob.

>* What other kinds of policy do we think the membrane pattern should
>enforce?

I thought the purpose of the membrane was quite clear - as above.
To me the problem is that in general a process can't tell when a
"capability" goes by if it assumes such rights can be communicated
in more than one form (e.g. more than the standard representation),
e.g. as a Swiss Number in this case.

>[1] Manifestly sensory is a weaker version of the E concept of "deep
>frozen".  A deep frozen object can't be changed.  A sensory object can't
>be changed through the sensory path.  For example, a read-only page key
>is sensory.  However if there exists a read-write page key in the
>system, that key can be used to change the contents of the page.

Sorry, but I don't understand how the above relates to the issue of
the attack.

--Jed http://www.webstart.com/jed/