[cap-talk] Users in object/capability systems (was: MLS gone bad, Lampson)

Valerio Bellizzomi devbox at selnet.org
Sat Nov 18 12:11:50 CST 2006

On 17/11/2006, at 16.54, Jed at Webstart wrote:

>At 03:15 PM 11/17/2006, Valerio Bellizzomi wrote:
>>On 17/11/2006, at 12.01, Jed at Webstart wrote:
>> >At 05:03 PM 11/16/2006, Valerio Bellizzomi wrote:
>> >><snip>
>> >>
>> >>I say it again in the hope that I write it clear and understandable:
>> >>user is represented in a system by programs, so I tend to think in
>> >>of "programs as principals", since a system only understands code,
>> >>system does not knows what a user is, the fact that ACL systems give
>> >>identity-based access is only an artifact of implementation, as I see
>> >>in an object/capability system, each user is himself a capability,
>> >>system code only understands capabilities.
>> >>If I am wrong please correct me.
>> >
>> >I'm not sure I understand you in the above.  You say that "the system
>> >not know what a user is" and that "a system only understands code".
>> >I think this depends on what you mean by the above.  Certainly there
>> >is code in every system that I'm aware of written to deal with users
>> >(people accessing the system), so in that sense I would say that the
>> >systems do "understand" what a user is.
>>Well, well, I'm playing the evil's advocate too, let me try to explain
>>this, because perhaps I'm jumping steps.
>>In Unix-like ACL systems you are given an UID, which is your identity in
>>the system (i.e. a number), the system does knows that this number
>>represents *your person* only by the username, and perhaps the "full
>>name". The "username" or even the UID, is to the system only a "hint"
>>the user is really you, or better, it is only a hint that it was your
>>intention to access the system.
>Hmmm.  The above seems a bit fuzzy to me.  Isn't the binding to the
>UID done when you (the real you, the person) authenticate to the
>system?  Sure, that authentication can go awry, but if it works properly
>then the binding to the UID can be fairly strongly assured.

Who tells to the machine that it is really me and not someone else using
my credentials?

>>I think it all stands on the knowledge of the user intention, because
>>if there was a full body scanner to acknowledge that effectively you are
>>the logging-in user, the system is not in a position to tell that it was
>>your intention to access the system.
>I don't understand your use of the term "intention" in this discussion.
>To me the "intention" of the user doesn't really matter.  I just want
>to know that the user is responsible for the actions that are
>logged as having been performed by the UID.

In this case we are not talking on the same wavelenght.
It is really easy to fool the machine to think that I am You (by stealing
your credentials), so that what I do on the machine appears as Your

>>It is impossible for the system to
>>know that you are not being coerced to use your credentials.
>>When I say "the system does not know what a user is" it really means
>>the system knows you only by the UID, so the UID is the representation
>>a person inside the system, it does not deal with your body or mind, it
>>a mere numeric representation of a person. That is, for the system you
>>only a number. Now, what if I steal your password and access the system
>>with your UID: the system is unable to tell the difference, it will
>>that I am You. This can happen with capabilities too, of course, the
>>system is not in a position to tell the difference between you and me.
>>So I argue that whatever security mechanism is in place in the system,
>>cannot save us from the theft of our credentials or from coercion, and
>>that revocation of credentials is the only mean viable to mitigate the
>>damage, of course. As you said it, there is homework to do about
>Stolen credentials/authority is of course a well known problem that
>has many approaches to deal with.  My primary concern in this
>discussion is how effective the systems are (acls vs. capabilities)
>assuming the authentication for initial authority is effective.
>See my most recent "Capabilities - the rub, an account" message
>for more details in this area.

We are not talking about the same thing. I thought your primary concern
was with revocation.

>> >In my experience with capability based systems (mostly RATS and
>> >NLTSS and the Elephant system at LLNL) a user (person) is
>> >authenticated when connecting to the system (e.g. with a
>> >password, certificate, whatever) and then they are given an
>> >initial process which is given access to the user's authority
>> >(e.g. a "home" directory containing all their capabilities).  From
>> >there that initial process (program) is responsible for granting
>> >controlled access to the user's authority to other programs
>> >run at the user's request.
>> >
>> >I'd be interested to hear if there are any models substantively
>> >from the above in terms of how people make use of object/capability
>> >systems.
>>My experience with capability based systems starts with EROS. I try to
>>find my way...
>And?  Does EROS work as above or otherwise?

It isn't yet clear to me how a running Coyotos system will work.

>> >Processes (domains running programs) beyond such an initial
>> >"user" process generally have their own agenda.  Generally any
>> >process will be initialized by some person.  After that it may
>> >get some of that person's permissions, some from other people
>> >and/or processes.
>>There is also the case of system service domains that are initialized by
>>the kernel. In this case there is no interaction with an user.
>>One could argue that such system domains are run on behalf of the
>>operator, but this is not true, they are run by the kernel.
>>The operator should not be a superuser, he is only given the
>>responsibility to manage some aspects of the system, but he is an
>>user, he is not entitled to access other user's content, not even kernel
>There is some "superuser" that has control of the system.   That person
>can make the system look like anything they wish.

Yes, but also the "system architect" can make the system look like
anything they wish.
The system architect is a "super-superuser".
So I think that if we talk about a "superuser", we have to define how much
we trust the System Architect, the Installer, and the Operator, otherwise
our talk takes a dead-end way.

>> >Particularly in a system like the NLTSS system (that I lead the
>> >development of) where:
>> >
>> >1.  Processes are permanent objects (that is they survive system
>> >restarts and are much like files in that regard) and
>>This is true also in Coyotos, as I read it, they have decided to keep
>> >
>> >2.  Capabilities are data (generally in a standard form including
>> >a network address for the server of the capability along with
>> >some generally secret/encrypted data),
>> >
>> >the issues of how people (users) manage their 'permanent'
>> >permissions, delegate such permissions, interact with
>> >various processes having their own permissions and do
>> >so in a manner that meets generally trusted computing
>> >criteria I think are quite sensitive.
>> >
>> >I regard any system in which capabilities are temporary
>> >(e.g. like open file descriptors that disappear on system
>> >restart) and can be depended on to disappear are in
>> >some ways cop outs that don't really deal with and
>> >utilize capabilities for managing access control.  With
>> >such systems one must ask how permanent access
>> >rights are delegated.
>>I can only see a very basic response: account capabilities are to be
>>permanent, and any delegation mechanism MUST have its revocation
>Can you explain what an "account capability" is?  That is, what
>operations are available on it?  What sorts of limitations are there
>on communicating such capabilities?  Such a capability sounds
>suspiciously like an "identity" capability and of course there
>are serious problems in that area.

To me the "account capability" in an object/capability system is the
equivalent of the UID in an ACL system.
I said it that I see serious problems, we don't understand each other for
a problem of terminology, but I think also our concerns are different.
My effort to start a capability definitions dictionary has not encountered
enought consensus as to motivate me to continue the effort, if you are
interested please let me know.

>I think perhaps the other "Capabilities - the rub, an account"
>thread might be the most fruitful way to proceed from this point.
>--Jed http://www.webstart.com/jed/ 

More information about the cap-talk mailing list