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

[Alaric B. Williams]

> I'm entirely underqualified to solve the issues involved, but someone needs to 
> think about how we either isolate different users in the same address space or 
> how we pass objects between processes running as different users.

With Lisp, we don't really need seperate address spaces, so long as we're
sure that all the binary code was compiled by our trusted compiler (ie,
only import source code), since we can just limit what's in the environment
we give the code.

However, we need a mechanism for choosing what's in this environment,
of course. A security model.

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.

ACLs are a pain when you have lots of identities.
Lists of accessible objects for each identity are a pain when you have
lots of objects.

Therefore, I prefer a system where for each identity there is a list
of "priveleges" they have, and for each operation, a list of
"priveleges" they need to perform it.

Note that I have subtly switched from "which functions are visible"
to "what user-level objects can be used". To reconcile these,
define groups of modules as user-level objects, and have a module group
"System" somewhere. The modules within "System" are available if you
have the appropriate priv, and would range from sending messages to the
console, to repartitioning the hard drive.
 
> Also, what exactly is a "user" in a LispOS? 

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. 

A user is a person, who is represented in the object space by a user-agent
object, which has an identity. The user agent represents them, much as the
printer object represents a printer - the user's actions go through
the user-agent, which presents an appropriate user interface to render
sections of object space to the user, and to convert the user's pathetic
carbon-based mouse clicks into remote function applications and all that.

> In the mail I sent about the 
> security needs of an SMTP server, I mentioned running .forward-style hooks as 
> the receiving user rather than as something like "root".  What does that really 
> mean in a LispOS?

A restricted environment, without

(system::reboot)

and friends! Without that binding, the program can't get at system::reboot
unless some other module provides a back door.

> Who out there understands these issues well enough to make a LispOS system a 
> safer network citizen than a Unix box?

I don't know, but I have some ideas :-)

For a start, don't make security system-based like Unix does it.

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:

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

etc...


ABW
--
Alaric B. Williams (alaric@abwillms.demon.co.uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html