Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Mon, 2005-10-24 at 11:57 +0200, Bas Wijnen wrote:
> On Thu, Oct 13, 2005 at 02:06:15PM -0400, Jonathan S. Shapiro wrote:
> > On Thu, 2005-10-13 at 14:42 +0200, Bas Wijnen wrote:
> > >   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.
> 
> Repeating this to make sure I understand what you mean: Processes may have
> private information from more than one source, and none of these sources is
> entitled to see it all.

It is more than that. Yes, none of the sources is entitled to see it
all, but also, the creator of the process is not entitled to see it all.

Let me give a concrete example. Suppose we wish to implement a password
authentication system. We want an object that implements the following
protocol:

        authenticator->confirmPassword("AllegedUserName") => bool

Let me ignore the trusted path issues for a moment -- I will assume that
there is a trustworthy way for the user to type their password safely
without disclosing it to the application. This is a very important
issue, but we can talk about it separately.

The problem we need to solve is that the application is untrusted, so it
cannot be given access to the password database. One way we could handle
this is the following:

1. Create a constructor for the ConfirmPassword program. This
constructor is NOT confined -- it holds a capability to the system-wide
password database that it will provide to the ConfirmPassword program.

2. Our untrusted application starts a new ConfirmPassword program, which
receives its capability to the password database from its constructor.
It opens a secure window, prompts for a password, does a check, waits
for a delay, and answers "true/false" to the untrusted program.

Notice that:

  a) the untrusted program NEVER has access to the password database,
     because it cannot inspect the runtime state of ConfirmPassword.
  b) ConfirmPassword is trusted code, but it runs out of resource
     supplied by the untrusted client.
  c) ConfirmPassword has access to a "trusted path" window that the
     untrusted client does not. [I have not explained how].

This is definitely NOT a violation of least authority. The
ConfirmPassword subsystem has exactly the authority that it requires,
and the sources of that authority have been factored in exactly the way
that is necessary to preserve the security of the password subsystem.

> This seems reasonable.  However, it doesn't cause problems if the actual
> parent, the constructor, _does_ have access to them.  That is trusted code,
> and it will not use it.  Of course it does violate the principle of least
> authority, and that should be enough reason to avoid it.

It is certainly possible to misuse the mechanism in a way that violates
least authority, but sometimes the minimal way of achieving separation
of interests is this kind of multi-source assembly.

> 
> > > 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?
> 
> See above.

Are we now clear that in EROS/Coyotos a parent does NOT have this
authority over its children?

> > > 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.
> 
> If the parent of a process has access to all its data, then you need to trust
> the whole chain.

But a parent does not -- and MUST not -- have this access.

> > 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.
> 
> You don't want the agent to be replacable by anyone except the user.  Making
> it replacable is actually a very good idea, since that means everyone will
> have a personalized password dialog.

Actually, the user cannot replace it either, because the agent has
access to the real password database and this must be protected. At
most, the user can choose from a selection of system-trusted
authentication tools.

>   Since fake programs cannot know how your
> dialog looks, it's much harder for them to impersonate it.

Nonsense. You *have* heard of screen dumps, haven't you?

This is actually a VERY hard problem to solve, but we should take it up
as a separate discussion. At the moment, I do not understand in
principle how to solve this if all authority comes from the parent
process.

shap