Shared address space and trust and what is a "user" [Re: Our

[BRIAN SPILSBURY]

> Now, I don't like the UNIX model, where a program gets the privs
> of who runs it; this allows people to write nice games that find
> out if root is running them, and then issues a shell command to
> create another root-level account... all programs should
> be "setuid", I think, with appropriate fine-grained access
> capabilities.

Delegation is something that needs to be handled.
Sometimes I need to delegate powers to another entity.

> Think of identities rather than users. A program that does some important
> task can have an identity of it's own, to prove to other objects, so they
> know to trust it. 

In lisp everything has an identity already - its reference.
This also has the property of being unforgable. Why do we need
to introduce a concept of 'identity' to clutter the world?

Capabilities seems to address everything you've covered here, and
without adding anything extra.
 
> (system::reboot)
> 
> and friends! Without that binding, the program can't get at system::reboot
> unless some other module provides a back door.

Yes, that binding gives the basic capability to use that object.

But what about a more interesting call like

(mail::clear)

obviously we all need to clear our own mail, sometimes we need to clear
other people's mail (for admin purposes, etc), and we might want to
be able to talk to other people's mailboxes to ask if they've read a
letter we've sent them yet.

So invisibility isn't a solution here at all.

A simple solution is to make the (mail::clear) call take a reference
to a mailbox, and a capability.

Inside the mailbox object it can see if that capability is the
'admin-mail-access-capability', or if its 'my-user's-capability-to-access-me'
and if so, it can proceed to clear, otherwise reject.

Note that we don't need to add anything new to do this.

> In my idea, every user-level object uses a security manager object
> (called a Hierachy). When a request comes in for an operation to
> be performed that needs some privs, the target object tells the
> caller to prove itself to the given Hierachy. If it succeeds in
> proving it's identity (passing a password, encrypting a block with
> a secret key shared with the Hierachy, etc), then Hierachy tells
> the target what priveleges the "user" has. A priv is just a Lisp
> object, such as:

Ok, this is basically a roundabout way to deal with forgable capabilities
with a capability vendor, but we don't need this level of roundaboutness
most of the time, capabilities in lisp are unforgable, since they're
references to unique objects.

> 'maintenance
> '(physical-access-to-floors 1 2 3 4 5)

These are examples of capabilities, except that 'maintainance can be forged
as symbols with the same print-name are eq. The list is unforgable.

We can have a look at a 'day in the life of a capabilities based system'

--

Telnet connection opened to telnet daemon.
Password and username entered, passed to the password daemon.
Password daemon verifies password/usernam, and returns the user's Agent
 to the telnet daemon.
Telnet daemon tells the Agent what streams to use, and then goes back to sleep.
The user then asks if there is any new mail.
The Agent contains a database of capabilities, some of these capabilities
 are references to the objects to use, others are used to unlock
 restricted functions.
Agent looks up the 'mail access capability' in its database and finds
 it, it then finds its 'mail owner' capability (for that _particular_ box)
 in its internal lists.
Agent does something like (new-mail-p box owner).
Box gets the (new-mail-p box owner) call, and checks that owner is a
 capability that gives access to check for new mail. Sees that it does
 and returns T.
Agent tells the user that there is new mail.


--

Ok, this is a simple example, but its secure, and we can do it _now_
with normal lisp, its secure, simple, scalable, etc.

I haven't addressed delegation of responsibilities because I haven't got
a good solution yet, single-user-capabilities (they stop being capabilities
when you use them) are a partial solution, but they don't make me happy.

Some java research indicates that Active Capabilities might be a solution,
but I'm not convinced yet.

I may well have missed the point here, if so, please correct me.

Brian