On Wed, 12 Oct 2005 15:38:10 -0400 "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote:
> I found Bas's note stunning, because I did not expect anyone to connect > the dots about setuid vs. confinement so quickly. It is a point that > usually requires several explanations. Indeed, setuid is not required at > all in a capability system. The only thing that Bas missed is that if > you have persistence you do not need a constructor server. Do you mean we can run a "constructor process" indefinitely as a translator? For example if I compile a program foo, which needs my capability bar, and make it accessible to everyone as /pub/jun/foo, I would do: run-with-cap bar /pub/jun/foo-constructor Then I get a capability to an idle process, the foo constructor. Let's call it P. I do: settrans --active --persistent /pub/jun/foo P Then P runs indefinitely as the active translator for node /pub/jun/foo. Later, whenever someone types /pub/jun/foo, the process denoted by P would spawn() the image (or fork() if foo-constructor contains an image of foo), passing bar to it. Thus, /pub/jun/foo will effectively be setcap'ed, without the need for a central server. But this scheme doesn't seem to leave room for others to verify if /pub/jun/foo would leak additional capabilities given to it. How is the verification done on EROS? Is it exact or conservative; ie can it have false positives? > 2. There is a set of applications. With very few exceptions, we want to > treat these applications as "presumed hostile". Most of the time they > will be fine. Sometimes they will have bugs. Rarely they will really be > out to hurt us. Where these applications are concerned we have two > objectives: > > A. Restrict these applications to the narrowest set of authorities > that will let them do their job. > > B. In the places where these applications require access to the > user's resources, make sure that the user has to consent > specifically. Our open/save-as mechanism is an example of this. Agreed. The problem is how to get that consent non-intrusively in an extensible manner. (I think extensibility is crucial here; see below.) > 3. There is a set of mediators. Each user has their own set. The purpose > of a mediator is to allow users to grant specific authority to untrusted > applications, but to do so intentionally. > > Let me give an example of a mediator, because this idea sounds like it > should create a horrible overrun of "is this okay?" queries, but it does > not seem to in our limited experience. > > You have all seen a conventional file open dialog box. There are three > differences in the EROS version: > > 1. The rendering isn't done by the application. > 2. The code runs in a separate, user-supplied process. > 3. The return value is an open file capability, not a string. > > Instead of calling a library routine to put up an open dialog box, the > library routine performs an RPC to the user-supplied "open/save-as > agent". This agent runs user-selected code and acts entirely on behalf > of the user. The agent has access to the user files. The word processor > does not. The agent interacts with the user to find out what file to > open, opens it, and passes the desriptor back to the file. So it seems in essence you have a user-interface server, sort of like a subset of GTK or Qt implemented as a server rather than a shared library. It has to be trusted, much like the shell is. What do I do if I'm not satisfied with the mechanism provided by the mediators I already have? Do I trust it blindly? Do I inspect code? It seems to me the number of components I must trust grows proportionately to the number of incompatible user interfaces. Or are you saying that the number is managably small? > Why do I say this about viruses? Because they're a perfect example of what happens if the principle of least authority is violated. Yes? -- Jun Inoue [EMAIL PROTECTED] _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
