Re: Restricted storage

[Bas Wijnen]

On Mon, May 29, 2006 at 01:37:47PM +0200, Pierre THIERRY wrote:
> Scribit Bas Wijnen dies 29/05/2006 hora 11:16:
> > - There are two types of restricted storage: read-only, and no-access.
> > Both types do not provide access to the capabilities of the running
> > program.
> 
> I don't see why there should be an automatic distinction between data
> and capabilities pages. This breaks the Flexibility requirement. I'll
> suggest the following permissions, that could be applied to data or caps
> or both:
> 
> - read/write
> - read
> - none

Theoretically I agree, but I don't see much use for anything other than
"opaque", "readable data", and "unrestricted".  Anything other than
"unrestricted" (to the user, I'm fine with "opaque" to the requestor) is very
special.  I don't think it's useful to build a whole system of sub-permissions
on it, because it will only result in accidental disclosure of certain parts
(because the default is unrestricted.  Making the default opaque would solve
this, but at a much too high cost IMO).

> I wonder if a write notice flag could be interesting.

Perhaps.  I suspect that it will cost performance in situations where it isn't
used though, which is unacceptable IMO (because it will hardly ever be used, I
suppose).

> > - When a user starts a sub-Hurd (or debugs a program in some other
> > way), it must be impossible for the program, or any of the programs it
> > spawns on its own storage, to become restricted.
> 
> Then again, this breaks Flexibility. This also breaks virtualization. I
> don't see why a sub-Hurd could not be a "real" Hurd, with all the
> possible features of Hurd.

It is.  And it behaves exactly the same.  And processes can restrict access to
memory in exactly the same way.  But those restrictions don't affect the
ability of the user who started the sub-Hurd to debug it (or spy on it for
other purposes).

> That is, a sub-Hurd would not only be used for debugging (which you seem to
> assume), but also for things like virtual dedicated servers.

Sure.  And this is very well possible.  It is the responsibility of the user
who owns the sub-Hurd to not look at it.  But it isn't impossible (unless it's
started on opaque storage, which I wouldn't advise).

> The only requirement of restricted storage about debugging is that a
> parent storage bank can deny to a storage bank allocated from it to
> reduce some of it's permissions.

No.  If P spawns C1, and C1 wants to spawn C2 on opaque storage, but fails
because P reduced its rights, then C1 can thereby see that it is being
debugged.  What should happen is that it actually works, and C2 _is_ opaque to
C1, but not to P.

> If P process spawns a C1 process in a translucent storage (that is,
> read/write), I obviously don't want C1 to be able to spawn a C2 process
> in storage that is opaque to P.
> 
> But it should be possible for C1 to spawn C2 in an opaque storage for C1
> that is translucent for P.

Exactly.

> The only question then is if it is desirable that C2's storage be
> translucent to someone. If P is a sub-Hurd where C2 is installed in a
> constructor that consider P part of it's TCB, that's fine.

If P owns C1, then C1 automatically trusts P completely.  And all of its
children (for which it provided both storage and code and all initial
capabilities) do as well.  So they do not need to protect against P being
malicious.

> > - If a user debugs a program (in a sub-Hurd or otherwise), the program
> > must not be able to detect this (except through contact with other
> > programs which can see it, but they are not likely to have
> > capabilities to them).  A program's behaviour must thus be completely
> > orthogonal to the fact if it's being debugged.
> 
> I agree. That just seems to me to be a fundamental axiom of software
> debugging.

I don't think Jonathan agrees with it. ;-)  He wants (in the above example)
that C1 can indeed start C2 in storage which is opaque to P.  If P really
wants to debug, it will prevent that, and C1 can detect this.  Ok, there are
workarounds, but no easy ones.

> But I think this makes the constructor unavoidable if you want
> restricted storage to be of any use, because the check that the storage
> is indeed restricted has to be made somewhere.

If you want to start a process in restricted storage, it must be started by a
service which checks that the storage is restricted.  It doesn't have to be a
constructor, and it certainly doesn't have to be the default way of starting
applications.

> > So Jonathan, I'm particularly interested in your answer to the
> > question: Do you agree that restricted storage (in the way I want it,
> > so non-recursive)
> 
> How is your restricted storage non-recursive?

If C1 creates an opaque sub-space bank from its own (to run C2 on), then it
doesn't become recursively opaque to C1's parents.

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