Re: setuid vs. EROS constructor

[Bas Wijnen]

On Mon, Oct 24, 2005 at 10:40:53PM -0400, Jonathan S. Shapiro wrote:
> 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.

While the constructor definitely isn't what I call instantiator, it is true
that the constructor could be allowed by the root server to create processes.
I'm not sure if it's practical, because book-keeping is hard if it's all so
decentralised, even if all processes involved are trusted.

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

My idea is that the task server makes a guarantee that the newly created task
doesn't hold any capabilities at all.  This is easily enforced, as any
capability the client holds must be given to it by the task server.  Also, it
cannot hold any objects to which third parties hold capabilities, as those
capabilities would have to be given to them after task creation.

As I wrote, having no capabilities at all is probably impractical, since that
would mean the parent cannot give the task its initial capabilities.  So there
probably is one, which is a communication path to the parent.

Technically you could argue that the task server is the parent of every task
(or the root server, or the kernel).  I chose to see it as part of the system
core, so a process can create a child by making a "system call", which really
goes via the task and root server.  I don't see constructors as part of the
system core, which is why I call them parents.  I guess you do, so you call
the process calling the constructor a 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.
> 
> By definition, any capability the parent adds is considered an
> authorized capability, and therefore confined.

If the parent is a constructor, and adds some of its own capabilities and some
from the instantiator, then (even though all capabilities are authorised by
the constructor) the child need not be confined from the instantiator's point
of view.

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

I'd leave that to the user.  The system should provide some known good choices
for it, but since they don't run with any authority the user doesn't have, a
user should be able to replace it.  Hardly anyone will want to, and it's a
very bad idea to replace it with something buggy, but I'd leave that decision
to the user.  If he wants to mess up his account, then I'm not stopping him.

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

With a very priviledged capability, only available to the currently logged in
user agent (or the login program, if noone is logged in).  It can use it for
things like xkill.  Using it will temporarily hang all windows (but not the
processes behind them, unless they choose to block on window events).

> That sounds like a denial of resource attack!

Yes, the user can force the computer in an unworkable state.  Noone else can
do that.  Since it's only the user's problem, I don't mind.

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

Well, my faith isn't so large, but I don't see much other options.  What I
think is needed is a way to tell the user that the window he's about to use
for typing in his password is authentic.  Using customised hard-to-simulate
windows for that is indeed security through obscurity.  I wouldn't want to
rely on it if there was an other option.

After thinking about it a bit, I do see an other option, though.  We could
reserve some hardware for this purpose, and use that.  It would not be
possible to simulate this, since the hardware can only be controlled by a
capability which they don't hold.  The hardware could for example be the caps
lock LED: When it's on, the screen is grabbed and whatever you type goes only
to the authentic password reading program.  When it it's off, don't type in
your password.

The bad thing about this is of course that you cannot use this hardware for
other purposes anymore.

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