[cap-talk] Re: Capability development principles - "no copy" seen as wrong

[Jed at Webstart]

At 05:17 AM 11/30/2005, Sandro Magi wrote:
>John C. McCabe-Dansted wrote:
>
>>Preventing a process from granting rights doesn't prevent the 
>>process from using the right in "bad code", it just means that it 
>>can't separate the untrusted code off into a subprocess with only 
>>the rights it needs. This is not POLA.
>>
>>Note that confinement similarly stops the leaking of rights, but 
>>does not require code to be one big indivisible chunk, as it lets 
>>rights be granted to smaller less privileged pieces of code trapped 
>>in the same confined area.

Perfect.  Thanks for that and your other comment John.

>This is absolutely the right pattern for partitioned capability 
>systems. Unfortunately, confinement simply isn't possible with 
>password capabilities (except perhaps with Jed's encryption scheme 
>-- I'll have to read it more carefully),

There really isn't much to the basic idea.  Just look at figure 6 under:

http://www.webstart.com/jed/papers/Managing-Domains/#s13

Without getting into the details of the transformations (for your 
information if you wish), every subject
(process) must be type aware of their capability as data 
blocks.  When they receive a capability they
transform into an internal form that is safe from being stolen.  When 
they send a capability they
transform it into a form that is only useful for the 
destination.  It's a bit fancier in that it even protects
capabilities in sending and receiving buffers and it protects against 
what I refer to as the "Reflection
Problem" (a variation on the Confused Deputy problem), but I think 
the above is about all you need
to know.

>which is why password capabilities can't enforce the *-property.

Glug.  I'm sorry to be picking up on this message so late.  Work on 
this list has been keeping me
up late recently.  I hope you got a chance to read:

Big Mac and the fallen *-Property:
http://eros.cs.jhu.edu/pipermail/cap-talk/2005-December/004392.html

It seems to me there is some spreading confusion about just what the 
"*-Property" actually
is, namely "can't write down" (down in sense of between 
classification levels).  You can read
above that I lead the design and implementation of an operating 
system that did indeed
enforce the *-Property (in so far as it is enforceable in a 
multilevel IPC system) and with
password capabilities.

Sometimes where I hear people refer to the "*-Property" as above it seems to me
that what they are really referring is to some ability to block 
capability communication.

Look, if you (any subject) trust a process (active object, any other 
subject) with
a capability, that's it.  You've trusted it.  You don't try to keep 
it from executing some
shared library that might manipulate the capability.  Why do you 
think it might be
helpful to try to block it from communicating the capability through 
IPC to some
such library routine?

I can tell you why you might want to let it do so.  Namely that just 
like you it needs
to ask for some service to complete the service that you asked of it 
with that capability.
It may in fact be that it doesn't even have all the capabilities that 
it needs to complete
the request that you have made of it.  It may need to communicate 
"your" capability
to some other subject that does have more permissions.

I can also tell you that you can't stop it from doing so in any case 
as it can proxy
your capability, but why force it to do so?

If, after it has completed your request, you would like to keep it 
from being able
to use that capability in the future, you should only give it a 
revokable copy of
the capability and revoke it after your request is complete.  That 
will mean that
it can't mediate any permanent sharing via that capability, but in this case it
seems that's what you want.

There just isn't any more protection you can get, so why struggle?

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