Re: On trusting its parent process

[Ludovic Courtès]

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.

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

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.

Thanks,
Ludovic.