Re: On trusting its parent process

[Marcus Brinkmann]

At Wed, 13 Jul 2005 10:58:38 +0200,
address@hidden (Ludovic Courtès) wrote:
> Marcus Brinkmann <address@hidden> writes:
> >>   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.

Right, but which constructor does the server use to identify the
buffer capability?  Where did it get the constructor from?  My answer
would be: From its own parent process.  IE, from the process that
created the constructor for the server process.  Right?

In the Hurd, this is how it is done:  The server would get a
capability to its own trusted mediators from its parent process, and
then it would use those capabilities to verify capabilities it gets by
the client.

Now, the question is: How can the server trust the capabilities it got
by its own parent?  Or in EROS speak: How can it trust that it is
identifying the capability wrt to the right constructor?  What is the
parent of the server?  The client instantiating the server through a
constructor, or the process creating the constructor?

> > 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).
> 
> Does this make sense?

It makes sense to me at least :)

> Now, one may argue that suid-root provides way more than mere
> authenticity proofs...

Yes, in UNIX, we only have one bit for this whole operation, so it
affects the whole execution environment: environment variables, root
directory, authentication handle, etc.  But not: argument vector, some
environment variables, and maybe some other stuff the suid application
knows not to trust.

So, it's a (hopefully well-defined) mixture.

In EROS, the constructor approach is much more flexible, of course.

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

I think it is an important question to ask, and I am grateful you
raised the issue.  I think it helped me to understand the purpose of
EROS constructors better.  For now, that's only half-wisdom as I
didn't verify it against the real EROS system, only against what I
believe about it, though, so take it with a grain of salt.

So, uhm.  Constructors sound like a good idea... have to squeeze them
on the wishlist somewhere... *scribble, scribble*

Thanks,
Marcus