[cap-talk] Re: Capability development principles - "no
copy" seen as wrong
Jed at Webstart
donnelley1 at webstart.com
Fri Dec 2 21:44:43 EST 2005
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:
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
>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:
It seems to me there is some spreading confusion about just what the
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
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
Look, if you (any subject) trust a process (active object, any other
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
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?
More information about the cap-talk