Re: On trusting its parent process

[Michal 'hramrach' Suchanek]

On Wed, Jul 13, 2005 at 10:58:38AM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Marcus Brinkmann <address@hidden> writes:
> 
> > I wish I knew Plan 9 and EROS better, so I could answer your question.
> > I don't understand what Jonathan Shapiro is saying in the mail you
> > refer to, so it's very hard to comment.
> 
> I'm not familiar with these systems either but it seems relevant to
> question this authenticity problem in the framework of the Hurd.
> 
> >>   1. The *only* way that a process in plan-9 can obtain a capability is
> >>   from its parent.
> >
> > [...]
> >
> >>   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.
> >
> > So what would such a way be?  The only way I see is by a kernel system
> > call which performs right amplification, and grants the process the
> > authority to authenticate capabilities.  Maybe this is how it is done
> > in EROS (I vaguely remember something like this, but the details
> > escape me).
> 
> Shapiro mentions this issue in IPC-Assurance.ps.  The problem in this
> paper is that servers must be able to determine whether they are using a
> TBO ("that is, [...] a process executing code that can be trusted to
> respond promptly" and that "will actually execute that code").  Then,
> roughly, there is an "Identify" operation that allows a process to check
> whether a given process is a product of a constructor.  And constructors
> are well-known trusted processes.
> 
> The point here is that the "Identify" operation is provided by the
> kernel and is guaranteed to be authentic.

In the Hurd, the server should only trust ports that were given to it
when it was started (supposedly by the administrator who sets up the
root and auth servers). Later connections are considered untrusted
client connections. At least that is how I understand it.

> 
> > Right.  It is unclear to me though if this actually is a problem.  If
> > it is a problem or not seems to depend on other aspects of the system
> > design.  For example, in EROS, you have constructors, which seem to be
> > a bit like "suid" applications in Unix.  If you start a suid
> > application, who is the parent task?  In the Hurd, it is the
> > filesystem providing the suid application, _not_ the user initiating
> > the execution.  The suid application receives an initial execution
> > environment which is a mix of the filesystems and the initiators
> > execution environment.
> 
> Right.  Or IOW: the suid bit in Unix and constructors in EROS are a
> means do distinguish the very few applications that rely on
> authenticity.  /bin/passwd is one such example.  For most other
> applications (those are not suid root), I guess we can say that
> authenticity of the system services being used is not required (for
> example, unlike `passwd', `xeyes' doesn't rely on / being a capability
> to the real root filesystem).

If you run a suid passwd from a filesystem, it authenticates against the
auth the fs server was given on startup. The "real" / fs server will
trust the main auth.

If you start passwd from your own / server you may rely on the main auth
or start your own. It will be suid in its context - your / server.

However, the passwd from "real" / would not
work with your own auth as your auth ports cannot be verified by the
main auth.

That way the system should be safe and give you the possibility to
divide your own rights between your processes (by using your own auth).

I guess that in EROS this flexibility is better expressed because there
are no default user rights that your processes posses. Instead, all
processes have no rights by default and are only allowed access to
selected file or other resource by communicating with another process
that is trusted to grant the privileges - such as a file open dialog.
Or that is how it is supposed to work once implemented.

> 
> Does this make sense?
> 
> Now, one may argue that suid-root provides way more than mere
> authenticity proofs...
> 
> > So, beside the other doubts I have expressed above, I also have some
> > doubts about how the word "parent" is used here.
> 
> Well, I don't think it really matters.  I was just questioning the
> relevance of this authenticity problem in the Hurd.  I had not
> considered the fact that the suid bit, among other things, does allow to
> make sure that a program will only talk to the authentic services.

The question is what is an authentic server. The filesytem server should
always implement its measurement of authenticity by talking to its auth.

If you run your own filesystem and your own auth, you cannot give away
more rights than you already posses, you can only impose more
restrictions. But you can use your own /etc/passwd that your suid passwd
program is allowed to modify.

Hope it makes sense :)

Thanks

Michal Suchanek