Re: fork, trivial confinement, constructor

[Eric Northup]

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