Re: setuid vs. EROS constructor

[Bas Wijnen]

On Tue, Oct 25, 2005 at 02:16:35PM -0400, Jonathan S. Shapiro wrote:
> 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.

Hmm, I think this is quite interesting, however it is probably not very
relevant for the Hurd at this moment.

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

If preventing a potential lockup costs that we cannot do useful things, then I
think that cost is too high.  Especially if there is no way that a hostile
application can accidentally gain the capability (the user will need to
specifically give it, either by using a shell command, or by going through a
menu structure which should never be used (and perhaps shouldn't exist in most
graphical "shells").  In other words, your dad isn't going to lock his
terminal accidentally, because he doesn't know how to start bash, and if he
did, he still doesn't accidentilly type "captransfer DisplayGrab
HostileAppID".

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

If only bad things can come from it, I agree.  But I see very acceptable uses
from grabbing the display (such as preventing to accidentally typing your
password in the wrong window).

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

Wow, this sounds like the window system is tied way too much to the core of
the system.  If this is true, then it isn't possible to log in over the
network and kill a process from there?  Or, in this case more likely, attach
not to your whole session but only to a terminal window (perhaps newly
created) from which you can kill it?  I can't imagine persistance makes a
system so fragile.

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

I like the idea of designing a system which your father can use, but not if
that means that I don't want to use it.  However, I don't think these are
mutually exclusive, the features I want can just be in a typical "developers
corner" such as the CLI, while the features he needs are in the place he uses
(and the features he doesn't need aren't there).  This is pretty much how it
currently works on GNU/Linux as well.

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

If the user explicitly wants this to happen, I think it should be allowed.  In
this case, to prevent locked-up sessions, this can also be resolved by
breaking the grab forcefully at login (so after an X reset and reattachment to
the session).  It doesn't really matter though: It is only used by developers,
and if it goes wrong, they will know what to do.

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