[cap-talk] membrane challenge

[Stiegler, Marc D]

> Interesting.  I guess you'd be willing to post your source?  
> Let me state this membrane challenge in a way that makes it 
> specific enough for me to attack it.

Source is posted at
http://www.skyhunter.com/marcs/membranesNotaries/

There are actually 4 membranes here, a simple membrane, a data membrane
(does not bother to wrap pure data in a membrane), an eventual data
membrane (does not bother to wrap a promise that resolves to pure data
in a membrane), and an EQ membrane (enables eq to operate with
membrane-wrapped objects). The one you should target, if you want to
target the model, is the simple membrane. 

I fully expect you can find at least an implementation breach in one of
these, they are tricky devils, and it would indeed be a great service if
you found some of those breaches before I include them in the secure
distributed patterns chapter of Walnut. There is also a powerpoint
presentation there that talks about these membranes. Eventually, the
powerpoint slides will be posted more permanently at 

http://www.erights.org/talks/efun/

where markm is keeping all the presentations from the class I am
teaching.

I did all these different membranes because I'm teaching capability
concepts, and I was working through examples, going from a simple one
that demonstrates principles, through increasingly more complex ones
that would be more suitable for production environments.

> 
> Let's say Alice has a directory D.  For some limited time she 
> wants to allow Bob to access the directory and to access the 
> capabilities in the directory, but at the end of the time she 
> wants to be able to revoke those rights.  To this end she 
> uses your membrane service. [Incidentally, why did you 
> implement two of them?  One wouldn't do?] She sends you the 
> directory capability D and gets back a membrane capability M 
> which she sends to Bob.  Bob can invoke M and fetch 
> capabilities out of it and invoke them.  In doing so he 
> actually ends up invoking new temporary membrane capabilities 
> that your service has created to extend the membrane.
> 
> Have I got a workable setup so far?

That's good. You're on a roll.

> 
> Now Bob may on his own have some capabilities.  He might
> on his own even have some of the capabilities in the 
> directory D.  However, let's assume there are some 
> capabilities in D that Bob doesn't have.  It shouldn't 
> otherwise matter what the capabilities are in the directory.

You have to include, in the list of capabilities that Bob has in
directory D, all the capabilities that are reachable via the
capabilities he is nominally holding: that larger set is his authority,
and that is what we care about, not his permissions.

Another element that should be excluded, if you want to have an
easy-to-state problem that is a strong demonstration, is rights
amplification patterns. If there are sealer/unsealer pairs rumbling
around, or notary/inspectors, or anything of that ilk, a much longer
discussion is needed to understand the security properties, the
legitimate claims, and the real breaches.

> 
> Now let me see if I understand the challenge.
> 
> I can set up the directory D and any capabilities and
> services in it.  I can implement arbitrary code in Bob
> for the time Bob is allowed to have the membrane
> capability M.  After I'm finished you pull the plug
> on the membrane.  If after that time and without any
> external granting of rights to Bob I'm able to execute
> code in Bob that exercises some of the rights that
> were in D that Bob didn't previously have then I will
> have breached the model and "nailed E's hide to
> the wall"?
> 
> Is that a fair statement of the challenge?  If not, please 
> suggest how it needs to be changed to make it fair.

I think that is good. Remember, though, we need to be allowed to try to
fix the problem you find. This is the first time an E membrane has ever
been inspected (indeed, just about the first time an E membrane has ever
been written, much less inspected :-) If we can fix it, then you've
nailed my hide to a wall, but not E's (is this my real role in E's
evolution, to be the blood sacrifice? :-)

Just as an anchor point, I showed an early draft of these membranes to
markm many months ago, and he was sufficiently unhappy with them he said
he'd write one himself... but never did. The published membranes are
substantially different, and somewhat improved, from those, so the
exercise is not without meaning (indeed, for a warmup exercise for
thinking about how to breach E code, it might not be a bad idea to first
attack some things that are likely to be flawed, so you can get a flavor
for what a flaw might taste like). Regardless, it would be a good
service to the capability community if this exercise simply forced markm
to write a good membrane :-)


--marcs