On Tue, 2006-06-13 at 18:12, Bas Wijnen wrote: > The last part of it however, is comparing trivial confinement to the > constructor. As it says, this list has not reached consensus about it. It's > probably a good idea if that happens, which is why I'm bringing it up. The > part I wrote can be used as a starting point. For the lazy readers, I'll > quote it here (if you don't understand from the context what the letters mean, > go read the whole thing): > > The difference between trivial confinement and the constructor is > one of control. With trivial confinement, P is in full control of > the process.
Also, P's parent, and P's parent's parent, ..., are all in full control. > For example, if P is a debugger, it could choose to > put some breakpoints into C before starting it. With the > constructor, this control lies with P1. However, P2 is likely the > one who will want to use the debugger. See my discussion of debugging at the end of this email. > The constructor is > explicitly designed to allow this type of control by the > programmer (or system administrator) over the user. I find this statement to be misleading. The constructor is designed to allow two *programs* (which might be mistrusting of each other) to compose some of their authorities and form a third program. *Either* of the two parent programs can also decide not to allow the construction if the resulting program would be unconfined, so the protection is symmetric, rather than one-sided. This is a statement about programs, not about humans; I am not at all concerned with programs' freedom. I believe that the constructor is compatible with preserving freedom for humans; if it turns out not to be, then those are bugs in the design and they should be fixed. > In the Hurd we want to enable the user to do these sort of things. > We specifically don't want the administrator to use such control. > So we do not need to provide the means for it in our system. (Note > that not using a constructor doesn't actually guarantee that this > kind of control is impossible.) I understand that there are many freedoms which the HURD's design must be able to protect. But I think that, by using an overly simple example, some other important considerations were missed. Consider UNIX systems. If the process being run has the set-UID bit, then the parent process P does not have the right to debug the child. The analogous scenario in a system with a constructor would be where P1 had given the meta-constructor some additional capabilities. The trivial confinement design as stated can't provide even the same securities as UNIX! Now, let me be clear: I am not suggesting that the HURD should encourage system administrators to be overly restrictive of their users' freedoms*. And I definitely agree that the HURD should not support DRM. But it is important to not throw the baby (usable security) out with the bathwater (DRM, unreasonable restrictions of users freedom, etc). *I see no problem with, for example, imposing quotas, or preventing a user from harming other users, even though such measures might be considered restrictions of freedom. > Therefore I am not so convinced that we want a constructor. It > gets in the way of debugging, for example, and it doesn't really > give any gain. The question of how to permit convenient debugging, without accidentally introducing security vulnerabilities is (as far as I am aware) a rather under-explored problem space. Many designs are possible; the one I'm about to propose is just a suggestion to start discussion. It seems to me that a reasonable policy would be that a program should be able to get a debug capability to a "victim" program if: -The program can provide capabilities to the space bank and CPU schedule from which the victim is running. AND -The program can provide copies of all the capabilities that were packaged into the victim's constructor by the meta-constructor. Also, if the program has received additional capabilities, while running, from the powerbox or through drag-and-drop, then the powerbox should ensure that the (human) user approves. That's a bit tricky to enforce, although maybe the powerbox itself could be the interface the users uses to request debug rights. . . . Why does all this matter? I often run shell sessions inside Emacs (or Eclipse, if I'm doing Java work on a fast computer). Now, Emacs is a great program. But it also obeys (presumed) hostile code -- there are a bunch of .el modules I've downloaded and installed. So, if I'm running on a system where parent programs have the unlimited authority to debug their children, then I'd have to stop using Emacs' shell features. (Assuming, of course, that we're using an OS where normal programs don't already have full read+write access to a user's home directory and debug authority for all programs started by a user.) -Eric _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
