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

Valerio Bellizzomi devbox at selnet.org
Fri Nov 17 17:15:51 CST 2006


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:
Each
>>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
it,
>>in an object/capability system, each user is himself a capability, and
the
>>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
does
>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.
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. 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
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 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 in by reading, reading, and re-reading the papers, I am not in
a position to tell that I am an expert. Unless I can get hands-on on a
running system and make experience, my knowledge of capabilities is purely
theorical and not at a high level. I only try to put my brain at work, I
mostly do it as an exercise for the future when I will write programs in a
running Coyotos system.

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

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

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

>
>--Jed http://www.webstart.com/jed/ 
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk





More information about the cap-talk mailing list