Re: New Mailing list archive setup

Reading that link about EROS brings up a good question. What is VSTa's
security model? It seems to not be the usual ACL but does not offer
pure capabilities, at least not in the KeyKOS sense. The kernel does
provide a way to securely manage a set of access rights for each
process, and processes can create new restricted ("forged")
capabilities. But the system relies on a global user ID table
(/vsta/etc/ids), which is interpretable by any process. In a pure
capabilities system, the capability handle would be opaque. Also,
access rights are stored in the directory entries just like POSIX.
Because the capabilties represent user ID's and not actual objects, it
seems like VSTA is more an ACL system.

It's doubly confusing I think because there are really two "systems"
involved here: One is the actual set of system calls: processes,
threads, messages, etc. The other is the emulation of functions like
open() and so on which would be system calls in other OS's, but are
really library functions that run inside the process.

A pure capability-based system wouldn't need to have an open() function
because that operation doesn't exist: a process either already has a
capability or it can't have it. So a capability is this sense
corresponds more to a connection handle in VSTa. In fact, what VSTa
servers do in processing a FS_OPEN message is simply giving the client
a reference to something which they have rights to. What's acceptable
in the following transaction is completely up to the client and server
involved; the server only uses the VSTa capabilities mechanism to
ensure that the client really should have that handle.

So the VSTa security system doesn't actually attempt to secure data
objects, as in traditional ACL, but instead connections between client
and server, which is more like a capability system. Of course, as part
of this system, many servers use access control lists.

Consider what would happen if we never used the FS_OPEN message (and
hence avoiding ACL), and instead had a way of passing the actual
connection handles around. The only way a process could get an open
connection handle would be from another process which had it (or a
superset of it). We would never need to ensure that somebody has
rightful access via access lists because there's no way they could pull
a handle out of thin air. They must have gotten it from somebody who
did have access.

The trick would be having a way to store these handles persistently.
Taken directly, that would mean that the run-time state of the all of
the servers would have to be saved also, along with the connections,
and that way all of the handles would be known to valid and secure. Now
I think I see why capabilties and persistence go together in an OS.

Also, the ability to embed a reference to a connection in a file (a
"portal" as someone I think on this list called them) would be really
nifty. That way we could avoid a lot of the nonsense regarding naming
and placement of files (a lively discussion we had about that on this
list, I remember.)
Received on Wed Mar 31 12:33:05 1999