Jim sent me a reply this morning that prompts some clarifications:
> > Capabilities can be obtained in two ways:
> >
> > 1. A process P1 can transmit a capability C that it holds to a process
> > P2, assuming that P1 holds a capability to P2.
>
> In other words -- for a process to grant a capability to
> another it must have some form of interprocess communications
> capability to that other process (P2). That's what I thought.
If you have a sharable read-write object that holds capabilities, similar to an EROS node, then you can transfer them via the shared object. Think of it as a shared memory mechanism, which some would consider an interprocess communication mechanism.
In EROS, the distinction is blurred by the fact that all capability invocations are identical; invoking a process start capability (doing IPC) involves precisely the same interface as invoking an object implemented by the kernel. This allows processes to "emulate" or be interposed in front of other objects transparently. Perversely, it also makes the implementation of kernel primitives a bit faster and simpler.
>
> > 2. [deprecated] A process can make a request of some system agent to
> > grant it certain capabilities on the basis of the program being
> > run, a challenge-response protocol, or some such.
This would be a "reference monitor" approach?
Perhaps, but perhaps not. An alternative example may help:
In KeyKOS, Nodes are a fixed-length array of 16 capabilities. There is an object called a 'supernode' which implements something that *looks* like a large node: a mapping from integers to "slots". The supernode is really just a process that manages a bunch of nodes for you.
The supernode is not a monitor at all, and doesn't need to be. It's security, and its willingness to transfer capabilities, devolve from the fact that it was fabricated by the client and initially held no capabilities of interest.
It is, however, another process P2 with which P1 might intercommunicate to obtain capabilities.
You might also imagine a supernode being used in the previously mentioned shared-memory style.
In EROS, supernodes don't appear to get used as much because we introduced capability pages that can be mapped into memory address spaces -- while they cannot be read or written by conventional load/store instructions, the supervisor implemented capability load/store instructions make use of the same address translation conventions to locate the capability page that they use to locate a data page.
> > In many situations where we are concerned about security, the
> > administrator is not cleared to know the authorities held by certain
> > programs. Appeals to the administrator therefore break down with
> > dismaying speed.
>
> I agree. This was an earlier comment on my part.
> I've since refined my personal definition of the term
> security to take the concept of 'root' or 'admin'
> out of it.
Excellent.
>From a mathematical perspective, it's important that the security
architecture not require a 'top' (in the sense of a lattice top),
which would have all authority.
> Wherever I use the term "subversion" in this thread,
> I'm talking about "misused authority" (from your
> web pages:
>
> http://www.cis.upenn.edu/~eros/project/novelty.html#
>
> ... item 4.3)
Ahh. That was a lot of text ago :-) I think I better go re-examine that page carefully, as I've learned some things since then.
Empirically, it seems to be easier to build code that doesn't misuse authority when the authority is:
The second point deserves amplification.
In UNIX, when a program calls seteuid() to raise it's privilege, ALL actions until the privilege is lowered operate with escalated authority. This has led to a great many bugs, which I probably don't need to tell you about.
A few early capability systems suffer from the same flaw -- invocation of a capability does not require that the capability be explicitly named; it's handled implicitly. This arose because early capabilities mainly dealt with memory access, where you wanted the lookups to occur as a side effect of performing load/store instructions.
In EROS, and in most capability and descriptor systems, the identity of the capability being invoked is explicitly provided:
Invoke capability X, performing operation Y sending data Z.
This tends to make the intent of the code clearer, and therefore makes subversion holes less likely to occur.
> There was a paper in one of the USENIX proceedings that
> described a programming trick to "approximate" capabilities
> via file descriptors. This is limited to parent -> child
> in most Unix implentations because that's the only way that
> open file descriptors are transferred (via inheritence).
Interesting. Also check out the I_SENDFD operation (STREAMS). I believe that UNIX-domain sockets support a similar function. Perhaps Hugh will know for sure.
> > Presumably you meant "... and ONLY my .plan file".
>
> Since I was clear on the idea that a capability is
> *specific* (as well as sufficient) I don't think it's
> necessary to add this phrase).
Sorry about that. As I said, sometimes I wasn't clear on who was speaking, and the definition of capability was going back and forth in that note...
> > Can you give a case in which prior knowledge of the access required is
> > not possible?
>
> I start an editor. After I've started it I want to open
> a file. The editor process didn't have prior knowlege of
> what file I would ask for. The parent didn't have prior
> knowlege and I may not have wanted to give the editor
> access to *every* document to which *I* have access.
>
> *I* want to know on a case by case basis which files
> this editor is accessing (which of "MY" files that is).
A couple of possible alternatives:
This can be accomplished by mediating the editor's access to your files through a "standard file access" package. You can then live with a situation where you trust the access package even though you don't trust the editor. Give the editor access to the mediating agent rather than the file system.
In this regard, Apple's "standard file" package is actually a real help.
2. Programs that serve as user interface "shells" indeed appear to have some unusual requirements of the kind you suggest. Editors, more often than not, act as shells. In the face of this, running an untrusted editor is problematic. Emacs, for example, is far too powerful for comfort. What, exactly, might all that Lisp code be doing behind my back if an opponent chose to write some nasty lisp code?
A contributing factor here is that the more flexible your editor is, the more files you load. At some point you say "yes" when the editor asks if you want to save everything.
An interesting design challenge: how to divvy things up so that your editing environment can be trusted when substantial parts of the editor itself cannot.
3. Another possible solution is a versioning "file" system, or granting the editor access only to a restricted portion of your files.
> My understanding of the the SAK is that it is a bit of
> support (at the hardware layer -- or at the lower OS
> layers at least) that establishes a "trusted patch"
> between your terminal and the system (or the security
> subsystem).
That is correct. The whole point is that all connection to your existing programs is disposed of, which probably means that the trusted patch should not have enough information to tell you which program was at fault.
> I'm glad to hear that EROS might finally see the light of
> day. I'm still a little concerned about the licensing
> model (since I'd like to see lots of third party work
> done on this system -- and I'm not sure that the currently
> described license will encourage that).
The license that is out there was a fast starting point to address an immediate need. I put it up in the expectation that I would liberalize later. I may not liberalize as far as you want, but let's figure out how to deal with that when we have a serious proposal on the table.
> How complete is the Linux/Unix subsystem? (Dionysix?)
The effort was abandoned. I concluded that it was easier/faster to complete my thesis by going down another path. I do intend to get back to it, and many of the things we have learned since then will make it easier to complete.
I'ld very much like to see this effort restarted, and I'ld be glad to see that part done and distributed under the BSD copyright.
> I still don't see any recent changes to your web pages
> -- like no discussion of the Distribution model.
EROS is not distributed, and will not be. While we solved the technical problems of distribution, we concluded as a result that the operating system kernel was not an appropriate layer at which to solve this problem.
shap