[Top][All Lists]

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

On trusting its parent process

From: Ludovic Courtès
Subject: On trusting its parent process
Date: Tue, 12 Jul 2005 15:05:44 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)


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.

Now, what does "authentic" mean in a system designed in such a way that
most system services can be replaced by the user?  Should programs be
allowed to rely on a specific implementation of a given service?

Just a few random thoughts...  Hopefully this will lead to a pleasant
discussion!  ;-)


reply via email to

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