the three security architectures

[Kragen Sitaker]

Norman Hardy wrote:
> At 20:12 +0700 00/06/23, cap@novosoft.nsc.ru wrote:
> >I urge to see simple administartion concepts for capability system. I would
> >like to see concepts that comunicate capabity system administration well
> >and make it simple and obvious. Capability sytems should be configured
> >currently in programatical way, ACL have declarative administration from
> >start.
> 
> This indeed needs to be done. I have proposed some ideas at
> <http://www.mediacity.com/~norm/CapTheory/Personal.html> along these lines.
> It is still a long way from answering your question.

It is easy to see how to implement your suggested admin tool ---
rendering the capability graph as a graph on the screen --- from, say,
a frozen system image, bits on a disk.  Or if you have hooks into the
kernel to let you dump the contents of all nodes.

It's not as obvious to me how to implement it in a program running
under the capability system itself.

One way to look at it: we don't care about nodes no running process has
access to.  So if we have a service key to every process, the KEYBITS
key, and some way to tell which of the built-in types of keys each key
belongs to, we can compute the graph.  Is this indeed sufficient?  Is
it possible to do this with less privilege?  Ideally, we'd like an
individual user to be able to run this tool on their own processes, and
on the flip side, we'd like to be able to grant people the ability to
configure, say, PPP, without giving them complete control over the
whole system.

We need KEYBITS to find out when we have two keys that lead to the same
object; otherwise, cyclic key graphs will become infinite graphs, and
even dags with subgraphs of significant in-degree can blow up
exponentially.

It seems to me that your suggested admin tool actually goes far beyond
what's available in principal-based systems; you can answer questions
like "what hardware devices does this user have access to?" as well as
"what users have access to this device?"

The other approach to building such a tool that occurs to me is to
duplicate the information in the capability graph in some other
location, such as a text file, and maintain the correspondence between
the two with administration tools.  This is similar to how RPM works.
I don't like it, mostly because it is fairly easy to break and hard to
fix.

I probably need to read the EROS specs before commenting further here.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)