Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Thu, 2005-10-13 at 14:42 +0200, Bas Wijnen wrote:

> > By the way, notice that the protection provided by the open/save-as
> > agent is *only* possible because the parent process does *NOT* have
> > access to the internal state of its children!
> 
> I don't see this.  But I'm not sure who you're calling whose child here.  In
> my terminology, the constructor is the parent, and the constructed process is
> the child.  If I understand you correctly, processes cannot create children
> themselves (unless they are constructors).  This sounds to me like unneccesary
> simplification.  It can cost flexibility, but it doesn't seem to if you have a
> publicly accessable meta-constructor.
> 
> So let's see how I would imagine the relationships between the processes (in
> the hurd, assuming no set-capabilities, so no constructors):
> login
>  \- shell
>      \- user agent
>      \- program
> 
> The shell and the user agent have mutual trust.

The story is a bit more complicated. First, login is not a parent of the
shell in EROS. The shell encapsulates the user's long-term session. It's
parent is the "newuser" command. The real problem I have here is that
the parent hierarchy isn't going to reveal what we need. I need a way to
draw a graph that captures several different kinds of relationships,
which is hard to do in ascii.

Here is the EROS parent/child tree:

  newuser administrative command
   |- space bank for fred
   |- home dir for fred
   |- session shell for fred
   +- directory of power box agents for fred.

User initial homedir contains a cap to user space bank and to window
system session for fred.

The power box directory is incompletely designed, but contains at least:

  open/save-as agent constructor -- this holds a dircap to homedir-fred
  net connection agent -- this holds a cap either to the systemwide
    network subsystem, or to an administrator-imposed software firewall
    on this

User now creates their program, and the parent/child tree is now:

  newuser
   |- home dir for fred
   |- session shell for fred
   |  \- hostile program
   +- directory of power box agents for fred.

The hostile program receives a read-only powerbox directory, a
sub-session capability subordinate to fred's window system session.

The session shell and the powerbox agents are collaborating, but neither
has any inherent operational dependency on the other. They do rely on
each other to collectively implement the protection of the user.

>   Every program trusts its
> parent (this is invariably true, if it doesn't it mustn't run).

I hope that by now it is clear that this is only true in a very limited
sense. Every program trusts its source of storage and schedule, which
comes from its creator. This is not at all the same thing as saying that
every program is willing to disclose anything and everything to its
parent. The trust relationship is more specialized than that. One is a
dependency on the parent for continued ability to execute. The other is
a matter of disclosure.

One of the big points in EROS is that trust is rarely "all or nothing".
The ability to factor trust in exactly the kind of way that we need here
is a powerful tool.

> Now as far as I see this works perfectly well when parents can access every
> detail about their children.  They usually will not want to use that power,
> but it doesn't break anything.

I do not understand why this access is required in your mind. Now that I
have given a slightly more detailed picture, can we work together to
discover where this assumption is coming from?

> The only problem it does give is trusted information from other sources, in
> particular passwords.  It means that in order to safely type in a password,
> you must trust the whole chain of ancestors of a process.  In practise I do
> not think this will be a problem, but it is a limitation.

It is a HUGE problem. Fortunately it is not true. You only need to trust
those elements on the trusted path between the keyboard/screen and the
process receiving the password.

There is a bigger problem, though: the user has to know that they are
typing at an authentic password handling process. This is a place where
you really don't want the agent to be replaceable/pluggable by untrusted
applications.


shap