[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setuid vs. EROS constructor

From: Bas Wijnen
Subject: Re: setuid vs. EROS constructor
Date: Tue, 25 Oct 2005 17:42:29 +0200
User-agent: Mutt/1.5.11

On Tue, Oct 25, 2005 at 11:06:43AM -0400, Jonathan S. Shapiro wrote:
> > 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.
> 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.

So no, it's not only the authority to mess up the account, it's also the
authority to lock a terminal up.  In most cases, I think users should have
this authority, because preventing it costs too much.  It should be possible
to do a terminal reset though, which should fix things (the ctrl-alt-backspace
kind of reset, not ctrl-alt-delete).

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

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

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


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

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]