Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Tue, 2005-10-25 at 17:42 +0200, Bas Wijnen wrote:
> On Tue, Oct 25, 2005 at 11:06:43AM -0400, Jonathan S. Shapiro wrote:
> > Unfortunately, this is not true. The authority to create a trusted-path
> > window is definitely NOT an authority that a user can be permitted to have.
> > It isn't simply a matter of messing up his account.
> 
> I was assuming that logging it to a terminal (be it locally or for example via
> the network on an X terminal) would give the user a capability to control that
> terminal.  This includes things like grabbing the display and the first
> available ouptut of the keyboard data stream (so before any sniffers, although
> that may not be reachable on an X terminal).  In other words, the logged in
> user temporarily owns the terminal as long as he is logged in.  I'm assuming
> here that each display and input device is only used by one user at a time.
> This may not always be true, if it isn't then probably none of them should be
> allowed to own the resource in question.

Bas: you are getting into a very complicated discussion about something
known as "trusted path" design. This is one of the most complicated
aspects of secure system design.

In one sense, you are correct that the user "owns" the display while
they are logged in. The problem is: this is only achieved if
applications cannot "grab" the display. For example, if a hostile
application can grab my mouse, it can prevent me from switching to the
terminal window that I want to use to kill the hostile application.

So I think you need to be asking the question:

  In order for the user to actually be able to exercise *control* over
  the display, what is required and what restrictions must be imposed?

In particular, we probably do NOT want any application to be able to
lock a terminal up, because then we cannot kill that application. It's
not even a security issue, really. It's a usability issue.

> > > > How is a display grabbed again?  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.
> > 
> > Users do not grab displays. Programs do. The problem here is that the
> > program grabbing the display may be grabbing for the purpose of stopping the
> > user from killing the hostile program.
> 
> The user agent holds a capability which allows him to grab the display.  This
> is one of the more dangerous capabilities that it holds (the one which allows
> writing to his home dir is worse though).  The user agent will only give this
> capability to a process when the user has expressly asked for it.  If it ends
> up in the hands of a hostile program, then something is very badly configured
> (or the user has been very stupid).

Sometimes the right thing is not to ask. In this case, there is no
conceivable circumstance where the correct thing is for the user to say
"yes". Under these circumstances, good design practice says that the
choice should not be offered.

Remember that in a persistent system, if you lose control of the
terminal session you have to delete the user's account to recover!

> I don't think that "things go wrong if the system is badly configured" is a
> good reason for not implementing features.

That's because you don't understand the demographics of real users. Your
model for users is yourself: a developer. My model of users is my
father: a guy who isn't entirely sure when it is okay to hit the power
switch. Design a system for you (and me) and we'll have a great system
for a couple of thousand users. Design a system where my Dad can feel
confident, and we can take over the world.

> > The entire idea of grabbing the display is a bad idea.
> 
> If the user should conceptually own the terminal, then he should have the
> right to grab the display.  Without it the machine feels like it's beyond the
> user's control.  And in fact, it is.

That is backwards. Precisely *because* the user must have primary
control of the display at all times, no program should ever be given the
authority to preempt the user's control.

shap