Re: setuid vs. EROS constructor

[Bas Wijnen]

On Mon, Oct 24, 2005 at 03:26:02PM -0400, Jonathan S. Shapiro wrote:
> On Mon, 2005-10-24 at 11:41 +0200, Bas Wijnen wrote:
> > On Mon, Oct 17, 2005 at 08:53:19AM -0400, Jonathan S. Shapiro wrote:
> > > I don't know how, in principle, to start a process more directly.
> > 
> > - Allocate some pages.
> > - Fill them with code.
> > - Ask the task server to make it a new process.
> 
> Why do you need a task server? The steps you describe are essentially
> the steps that the constructor performs.

In L4 there are a few priviledged system calls.  They can only be made by the
root server.  In the Hurd we decided to make the root server a proxy (because
it is so special, it shouldn't really have anything in it which a user may
want to substitute).  We have some dedicated servers to give the user access
to those system calls.  The task server is the only one who can do address
space and thread creation, so to do this you need to use it.  A user replacing
the task server really is setting up a proxy task server (which will of course
only be used by children of that process, not by other users, unless they
specifically ask for it).

I would expect a constructor to take exactly these steps.  What I'm saying is
that putting the steps in a constructor and not in the instantiator is a level
of indirection, so without a constructor you are starting the process more
directly.

> > > > > Yes, the constructor has the ability to provide external
> > > > > capabilities.  In fact, it *has* to, because the initial address
> > > > > space capability for the yield is an external capability.
> > > > 
> > > > I think in the Hurd we would do this via a capability to the task
> > > > server..
> > > 
> > > This would work functionally, but it would have a cost: you would no
> > > longer be able to test confinement.
> > 
> > You would, since the task server is a trusted server, and the address
> > spaces it gives out are guaranteed not to leak.
> 
> It cannot make this guarantee without doing all of what the constructor
> does.

I don't see why not.  What the task server does is simply "split these pages
owned by the requestor off into a new address space".  It doesn't alter the 
data in
them, and in particular it doesn't add any capabilities (well, I guess it
needs 1 to start negotiations with its parent).  So the process
requesting the generation of the address space knows that the child has only
one capability, which is a communication channel to the parent.  Now I expect
the parent to add some capabilities, after which the child can "really" start
running.  If the parent didn't add unconfined capabilities, the child will be
confined.

On Mon, Oct 24, 2005 at 03:37:35PM -0400, Jonathan S. Shapiro wrote:
> On Mon, 2005-10-24 at 11:57 +0200, Bas Wijnen wrote:
> > 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.

I think we mean different things by "parent".  I am using the word for the
process which fills the initial memory of a process with code.  In case of
EROS, every parent is a constructor (except the parent of a constructor, which
is the meta-constructor, and the parent of the meta-constructor, which
probably doesn't exist).

What you seem to mean with it is what I call the instantiator, in EROS the one
who calls the constructor.

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

The violation of the principle of least authority I was talking about occurs
when the parent can inspect the memory of its child.  However, the parent of
ConfirmPassword is the ConfirmPasswordConstructor, which is also trusted code.
And since a constructor is probably not too complex, it may not be a problem
if it could potentially access private data, because we know that it doesn't.
In other words, we can consider the constructor code (the part which is
inserted by the meta-constructor, not the part which is inserted in the new
program) part of the TCB, which makes having access to private info no
problem.

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

Note that the access wouldn't really be required, but (at least in L4) it
seems like it would take some effort to avoid it.  I'm just saying that I
think it isn't really a problem.

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

I'm not sure about the details of constructors, but they're the only ones
which have children in EROS as far as I understood it, and it doesn't really
matter if they have the authority, because they will not use it.

Obviously, the instantiator does not have this authority.  It never did in any
of my plans either.

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

I'd split the process up in two parts: the actual function, which returns a
bool and cannot be replaced, and the front-end which is presented to the user
for typing in the password.  The latter should be customizable (and it should
be customized, too).

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

Of course.  But I'm assuming a secure system, where hardly any process will
have the right to make one.  If they're allowed to open a window at all, they
still aren't allowed to inspect windows from other processes.  And they
definitely aren't allowed to do that while the display is grabbed by the user
agent himself.

One more thing: In a different e-mail (which I can't find anymore), you asked
why I insist on giving the parent access to the memory of the child.  I don't
really, this is just the way it is in the current design (where the parent
MAPs memory to the child), and I didn't see a reason to change that.  If it
would be useful, it could be changed of course.  However, with all tasks'
parents being constructors, I see even less reason to worry than when only
priviledged tasks are started by a constructor.

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