Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Tue, 2005-10-25 at 00:28 +0200, Bas Wijnen wrote:
> 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.

The constructor *is* the instantiator. There is no added level of
indirection. Perhaps it would help to think of a multiply instantiated
task server, where each task server is responsible for instantiating
exactly one type of process. That would be a constructor.

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

What guarantees does the task server make about any initial capabilities
that are held when the process is created? How does it test to ensure
that these guarantees are met?

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

By definition, any capability the parent adds is considered an
authorized capability, and therefore 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).

Yes. Thank you. We were indeed using the term "parent" differently.

In EROS: the metaconstructor is considered to be simply another
constructor. As you suspect, it is one of the primordial processes. The
metaconstructor is not built from a constructor.

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

Yes.

> The violation of the principle of least authority I was talking about occurs
> when the parent can inspect the memory of its child.

Yes, that would indeed violate least authority. It sounds like we are in
agreement about this.

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

The constructor code is indeed part of the TCB. It is a case of "trusted
code that manipulates untrusted state" where the untrusted state is the
components that will go into the newly created process.

Ignoring comments and blank lines, the constructor is 360 lines of code.
The metaconstructor is only 175 lines.

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

Unfortunately, the front end cannot safely be customized either. The
issue is that the front end has access to a trusted path to the window
system. If the front end is compromised, then the trusted path is
compromised. If the trusted path is compromised, then the user no longer
has any ability to have any confidence at all about where their input is
going.

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

How is a display grabbed again? That sounds like a denial of resource
attack!

Your faith in the difficulty of simulating a dialog box is touching.
Unfortunately, there is overwhelming real-world evidence that it is
misplaced. You are proposing a form of security by obscurity. It doesn't
work.

> 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 think this was a result of our confusion about the term "parent".

shap