On global file systems (was: On trusting parent processes)

[Jonathan S. Shapiro]

My reply got long, so I'm breaking it into two pieces.


Ludovic wrote:

> LSM talks by Shapiro (on EROS and Coyotos) and Forsyth (on Plan 9) were
> quite insightful.  I just found this followup:
> http://www.coyotos.org/pipermail/coyotos-dev/2005-July/000138.html .
> 
> What strikes me in this message is this:
> 
>   1. The *only* way that a process in plan-9 can obtain a capability is
>   from its parent. This is a problem if the capability refers to
> important
>   state and the parent is untrusted. Consider, for example, that the
>   "passwd" program can no longer trust the content of /etc/passwd,
> because
>   it has no way to know if it is receiving an authentic copy of the
> file.
> 
>   [...]
> 
>   This differs very strongly from the status in EROS/Coyotos, where
>   *authentication* capabilities are not considered to be "holes" for
>   purposes of confinement. An implication of this is that the capability
>   which answers the question "Is this capability a capability to an
>   authentic X object" can be widely distributed, and can come to the
> user
>   in a way that the parent process cannot interfere with.
> 
> In the Hurd, processes get capabilities to the root filesystem, to
> `auth' and friends from their parent process.  This is very convenient
> because it allows to run processes in a "sandbox".  OTOH, this makes it
> impossible for a process to make sure it is talking to "authentic"
> servers, as in the Plan 9 case above.

First, a small but powerful point: EROS does not have a root file
system. Any universally shared, mutable resource is a security problem,
and a globally shared file system is the mother, father, aunt, uncle,
and several cousins of all such problems. Confining a resource like this
is very very (very) difficult.

Instead, EROS has multiple file systems. Each is implemented by a
separate process instance, and users make many instantiations of this.
Some of them will be shared, but they will be shared narrowly, and only
by passing capabilities around over previously established channels of
communication that (by their existence) prove the authority to share.

In practice, there has only been one file system implementation in EROS,
and many instantiations. There is nothing that would prevent a user from
building their own file system implementation, but there has never been
a need. If a critical server accepted an open file as input, a new file
system would present a bit of a problem: the critical server cannot
perform a read() operation unless it knows that the operation will
return. A memory region is probably a more appropriate mechanism to
handle this sort of dependency/risk management issue.

But let me make sure that the statement is clear: the problem arises
because the server is critical and because it is calling untrusted code.
In this scenario, the server must not fail. A server of this kind
necessarily carries a greater burden of paranoia in its implementation
than most programs do. Much of our recent work in EROS has been
discovering and codifying design patterns that are (a) paranoid enough
to work, but still (b) high performance. I am trying to emphasize that
this is not a general objection to plugability.


shap