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

Jed at Webstart donnelley1 at webstart.com
Fri Nov 17 18:54:12 CST 2006

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 terms
> >>of "programs as principals", since a system only understands code, the
> >>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, and
> >>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 really
>represents *your person* only by the username, and perhaps the "full user
>name". The "username" or even the UID, is to the system only a "hint" that
>the user is really you, or better, it is only a hint that it was your real
>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.

>I think it all stands on the knowledge of the user intention, because even
>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.

>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 that
>the system knows you only by the UID, so the UID is the representation of
>a person inside the system, it does not deal with your body or mind, it is
>a mere numeric representation of a person. That is, for the system you are
>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 assume
>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, it
>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.

> >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 different
> >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?

> >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 ordinary
>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.

> >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 mechanism

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.

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