Re: Part 2: System Structure

[Bas Wijnen]

On Tue, May 23, 2006 at 11:43:10AM -0400, Jonathan S. Shapiro wrote:
> > Protection for programs which are about to get capabilities which must not
> > be disclosed to the wrong parties is fine.  That is not what this is
> > about.  This is about protection from the user who owns everything that's
> > known to the program.  That must not be possible.  The user must be in
> > complete control in such a case.
> > 
> > In particular, that means that when starting a sub-Hurd on a transparent
> > space bank, it must not be possible that
> > - A part of the sub-Hurd becomes opaque
> > - A part of the sub-Hurd can see that it is running on a transparent (to the
> >   parent Hurd) space bank.
> 
> Okay. Just so we are clear,

Thank you.  I appreciate the effort to avoid misunderstandings.

> there are two possible views about opacity, and you are choosing one.

I haven't made a choice yet, actually.  And I think your distinction doesn't
quite capture the choice I was making.  I'll try to explain.

> The two possible positions are:
> 
>   1. The default should be translucent, but it should be possible for
>      a user to choose to execute an opaque program.
> 
>   2. The designers should not allow the user the freedom of this choice
>      in the absence of extensive new development effort, and therefore
>      mandate that all banks be translucent.

You are (perhaps intenionally) forgetting the option that the default is
opaque.  I have indeed chosen to reject that.  However, note that I have only
chosen to reject opaqueness to the user.  I do not have theoretical objections
to default opaqueness for the parent process.  As I said before, for me the
process doesn't have rights.  The child process doesn't have the right to
demand opaqueness, but the parent process also doesn't have the right to
demand transparency.  The user does have this right, IMO.  Of course if
there's an other user (or "the system") involved, such as with ping, then that
other user can also demand opaqueness.  Things get complex if the demands
don't match. :-)

> It appears to me that you are choosing position (2).

No, actually if I have to choose from those two, I think I'm tempted to choose
1.  What I said is that I would like to choose 2 if that would not raise any
problems.  I now think that the ping case may actually show a real problem for
which users will want to provide read-only memory.  The competition case needs
full opaqueness.  I'm still open to both, in fact.  But transparent storage is
the default for me, and anything else will need justification.

The point I was trying to make is that the system should not allow programs to
make things harder that are possible anyway.  That means that the machine
owner must simply be able to see everything in the system if she desires this,
and a program must not be able to hamper debugging it if all users which
provide capabilities to it agree that debugging is a good idea.  In the usual
case, all capabilities are supplied by one user.  If that user wants to debug
the program, there should be noone who can make it harder, and in particular
not the program itself.

If this would be allowed, then what really happens is that programs are given
rights to "want" things.  Since programs don't have a will, this effectively
means that programmers can let their programs execute their will.  To some
extend this will of course happen anyway, but I think the system should not
provide additional support for this.  Once a program is on my computer, I
should be considered the owner of that program (from the system's point of
view, juridically things are different of course).  That means that the system
should not allow the program to do things that I don't want.  Forcing me to a
choice between hacking the program and running it on an opaque space bank is
certainly something I don't want.

Things are much more complicated when more than one party provides
capabilities.  However, in the end everything is owned by the machine owner,
and so for her no limits should be imposed by the system (which doesn't mean
the machine owner doesn't limit herself, but that's a personal choice).

Note that in the case of a sub-Hurd, the "machine owner" of this sub-Hurd is
the user starting it.  That's why no process within the sub-Hurd should be
able to get protection against that user.

> Speaking on a purely subjective basis, I find this incredibly arrogant,
> and I think that the users will too.

I will not deny that I am indeed incredibly arrogant, at least in some cases.
This is one of them.  I think we (I'm arrogant in plural, cool huh? ;-) ) know
much more about operating systems than the user, and so it's up to us to make
choices for which knowledge about them is needed.  That includes imposing
policy.  Open-source people will probably say "hey, we're just engineers, it's
not our responsibility what the thing is used for".  I strongly disagree.  The
users simply don't know enough about it.  There are choices which influence
their lives, and they aren't educated enough (in this field) to decide what is
right.  We are, and I think it is our duty to make those choices in a way that
is in their best interest.  Not doing anything and letting them figure it out
is a choice, too, and IMO it's a morally objectionable one.

So yes, I am arrogant, and if the users read this they will likely agree.  I'm
not sure if they have a problem with it, though. ;-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature