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

Jed at Webstart donnelley1 at webstart.com
Fri Nov 17 14:01:11 CST 2006


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.

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.

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.

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

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.

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




More information about the cap-talk mailing list