Re: Restricted storage

[Bas Wijnen]

On Tue, May 30, 2006 at 09:57:47AM -0400, Jonathan S. Shapiro wrote:
> > There is one very important point though.  I think those restrictions can
> > easily be implemented in the user session.  This means that we can just
> > build a system with no support for restricted storage, and add it if we
> > find that we did need it after all.  However, Jonathan doesn't seem to
> > agree.  At the moment I still think he doesn't quite understand what I
> > mean.  However, if he does and is correct that it cannot be added later,
> > we would need to decide this before building the system.
> > 
> > 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) can be implemented later, in the user session, or do you
> > still think this is very hard?  If you think it is very hard, why?  And
> > related, do you think there is anything wrong with non-recursive
> > restrictions (so that the process starting a sub-Hurd can always read and
> > modify any storage inside it), in the sense that it makes things
> > impossible which should be possible (considering our objectives)?
> 
> I haven't followed your example closely enough to understand what you
> mean by "non-recursive", and I don't have time to dig through the
> archive.

Sorry, I realised that it is recursive when looking from the other side, so
this was really a confusing remark.  I was speaking of opaqueness that is
implemented by the parent, and works against siblings, but not against
that parent.  So if P spawns C and C spawns D on opaque storage, D's storage
is opaque to C, but not to P.

> I do not find the entire "private drivers" idea to be motivating. It
> will be ten years before hardware that can support this in the general
> cases is available. The special case of writing a user mode driver on
> top of a generic layer (e.g. SCSI generics, or possibly a similar thing
> for USB) really isn't a driver at all; it is simply a format converter.

If you want to call it that, then we just want format converters.  But to the
user it really is a private driver, it just doesn't work on all devices.  But
if I bring a usb network card and some software to make it work, then that
software is what I call the driver.

> Concerning restricted storage: I think it is *impossible* to add later,
> and I have stated the reason many times already:

I must have missed is all these times.  That could be because it doesn't
actually hurt any of the objectives I had in mind.

>   Removing restricted storage is not simply a minor change in feature
>   set. It is a major change in the entire philosophy of system design.
>   If the initial system incorporates a "translucent storage" assumption,
>   code will be written to assume this, and it will later become
>   impossible to add opaque storage compatibly -- not because it is
>   technically impossible, but because the changes required to fix hidden
>   assumptions will be too large.

So what you are saying is that it is impossible to build a system where the
default is transparent storage, and then change that default into opaque.  I
am convinced that this is indeed the case.  However, I am very sure that we
don't want a default of opaque storage.  We may want to allow opaqueness for a
very limited set of applications.  It is no problem at all if all the other
programs can't handle opaque storage, because they aren't going to get it.
When adding opaqueness, we just need to change this limited number of
applications to actually use it.  That's very possible.

I have the feeling that you are assuming that I want to give full access to
the storage of a new process to its requestor.  This is not actually the case.
What I want is to give full access to the storage of any program (indirectly)
started from a user's session to that user.  Again, it's not the programs that
have rights.  It's the user.  From the program's point of view, it very well
fits POLA to have opaqueness, and there is no problem with it.  There is a
problem with opaqueness against the user, and that's what I want to avoid.
(This problem is that the user gives up his rights with it.)

I'm saying that this is possible in a way that doesn't implement verifyable
opaque storage which a constructor could use, but it does allow to add it
later without much trouble.  The question to you was if you agreed with that.

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