l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Part 2: System Structure


From: Jonathan S. Shapiro
Subject: Re: Part 2: System Structure
Date: Tue, 16 May 2006 10:16:47 -0400

On Tue, 2006-05-16 at 01:12 +0200, Pierre THIERRY wrote:
> Scribit Bas Wijnen dies 16/05/2006 hora 00:47:
> > What I want to avoid is this:
> > - User starts program P
> > - Program P calls server S, which needs storage
> > - P provides some of its storage, and makes it opaque
> > - User cannot inspect and/or change his own storage, because P
> >   opaquified it.
> > 
> > If this is a standard operation of a space bank (that is, one that you
> > get access to when you create a new sub-space bank), then this is
> > possible.
> 
> Whatever standard operation a sub-space bank provides, it changes
> nothing about the upper space bank. If user has read/write access to it,
> it won't change. If anything asks for opacity in a space bank, then
> recursively each space bank in the hierarchy must accept to give away
> inspect capabilities to the specified resource.
> 
> At least this was the only sensible way to operate, as I see it.
> 
> > > > If the default is to use opaque storage, then that dialog would be
> > > > very annoying (popping up at every single process instantiation)
> > > Why the hell should it be the default?!
> > Because it is in EROS, AFAIUI.  As far as changes aren't specified I'm
> > assuming the EROS implementation (as far as I know about it).
> 
> I found very few information about constructor implementation in EROS,
> where did you find that opaque storage was the default for every process
> instanciation?

What Bas is saying is complete bullshit. EROS doesn't do this "because
it is EROS". EROS does this because 40 years of experience says that the
default has to be opaque or security fails.

Pragmatics first:

Making the space bank transparent won't really help. The space bank does
allocate address spaces. It allocates pages and nodes. In order to get
useful information out of that, you would need to know how the pages and
nodes are arranged, which is very hard.

If you really want to make constructors transparent, there is a MUCH
easier solution: add a new "create" call to the constructor that returns
a process capability to the requestor (the process capability names the
new yield). This gives the requestor all of the same authority that the
process itself has.

Rationale:

Opaqueness is like virginity. Once you give it up, you can never get it
back. In consequence, if *any* process *ever* requires opaqueness, the
default must be to make storage opaque.

This is fundamental. There really *are* programs that need to manage
sensitive state, and you really *don't* want those programs (in most
cases) to have to run off of system-supplied storage. The system design
that Marcus proposes relies on a process hierarchy with trusted system
processes close to the top. A problem with this design, which will
become apparent to developers after 2-3 years of coding, is that this
design only works in a transparent storage design IF those servers
supply the storage for all of the operations that they perform (i.e.
they never rely on user-supplied storage). The problem with this is that
there is a "free rider" problem that leads directly to denial of
resource.

I want to be clear: the design that Marcus has proposed has eliminated
more of these kinds of issues than I would have expected. It has not
eliminated all of them.

Policy:

I am very very concerned about the extremist ideology of transparency
here. This goes ORDERS OF MAGNITUDE beyond what is required by GPL or
FSF. GPL does not say "if you run my program, you must disclose all of
your data". It does not even say "if you modify my program, you must
give away the modifications". It says: if you *redistribute* the
modifications *then* you must disclose. It notably does NOT say that if
you connect two programs that you run with an IPC pipe then you must
disclose.

GPL works extremely hard to strike a careful balance between privacy and
disclosure. It is instructive to note that it protects *both* very
strongly. Just as I cannot modify GPL to reduce your obligations of
disclosure, I also cannot modify GPL to *increase* your obligation of
exposure. Another way to say this is that I cannot modify GPL to
*decrease* your right of privacy in the context of private use. I cannot
narrow the conditions under which privacy holds.

The "no encapsulation" or "transparent storage" policy is fundamentally
a step that increases the users obligation to disclosure by reducing the
conditions under which private execution can be accomplished. It is
based on an assumption that the conditions under which privacy should
hold should be narrowed greatly, and that users of GPL software should,
by default, be required to publish their uses.

I believe that this proposal fundamentally violates the privacy
protections that are built into the GPL, and I question whether it is
appropriate for an FSF-hosted project to do that.



Jonathan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]