Re: setuid vs. EROS constructor

[Bas Wijnen]

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.

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.

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

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

> 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.  Since fake programs cannot know how your
dialog looks, it's much harder for them to impersonate it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature