Restricted storage

[Bas Wijnen]

Hello everyone,

We've been discussing the options of restricted storage a bit.  These
"restrictions" are from the supplier of the storage.  It is possible that
there are different restrictions for different suppliers (that is, for the
parent, and for the parent's parent, etc).  I'll say some things which I'm
pretty sure about first:
- 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.
- 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.
- 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 think Jonathan does not agree with the last two points.  These are design
choices, and he makes different choices.  That's fine.  I'm just saying that
these are the choices I expect the Hurd to make.

Now then, on to the actual content of this e-mail.

So far, there have been two examples where restricted storage seemed needed:
Running a competition, and ping.  First of all, in all cases the problem can
of course be solved by letting the party who wants to keep the secret pay for
the storage.  This however is in some cases the wrong party, which usually
leads to DoS opportunities.  Then again, this is not always a problem, because
there is a limit on the amount of storage that is used, for example
proportional to the number of users on the system (if the number of
simultaneous uses by the same user is limited to some number).  In such a
case, it may be acceptable to let the secret-keeper pay for the storage.

I'm particularly interested in ping at the moment.  We can say that we'll use
the "limited number of simultaneous uses per user" approach, but we would
really prefer to have no limits on this.  So in that case we will need
read-only storage.  Marcus stated that because the network driver is provided
by the system, it can simply take some user storage and give it back later.
In other words, the system can choose to use opaque (or read-only) storage,
even if it doesn't allow this functionality to normal programs.

This last statement is of course true.  However, the one before it may not be.
Assuming that we have a good driver framework, it is very well possible that I
plug in my own network card on a usb port, which connects the machine to a
couple of other computers.  Suppose this happens on a university, and some
students arrange this setup so they can all use those other computers.  Since
I'm behind the terminal with the network card, I own the usb bus and provide a
network driver for my card.  The other students will tell their shell that
they want to trust my driver and use it for communicating with the other
machines (not a lot of trust is needed for that, but they must be explicit
about using my driver, of course).

In that case, my driver will be unable to use restricted storage if the system
doesn't provide that functionality to "normal" programs.  So then there are a
few options:
- My driver doesn't support ping, or only in a limited way, so it uses
  "constant" storage (where this "constant" is a function of the number of
  users on the machine).
- My driver fully supports ping, and is vulnerable to DoS by its users (which
  are all trusted (in a real-life social way) students, so this might be
  acceptable).

In both cases though, I cannot use the "normal" network driver, because that
uses (at least) read-only storage, which is unavailable to this one.  So there
is a need for two different driver programs depending on if it is system
installed or not.  This is unfortunate.

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)?

Thanks,
Bas

Ps: I'm not only interested in Jonathan's opinion, anyone else who has
something to share please reply as well. :-)

-- 
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