Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

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

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.

> > > 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!
> 
> 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 entire idea of grabbing the display is a bad idea.


shap