xfdm

[Tim Tassonis]

Hi Auke

> that should not be the case... a login manager should run *as* root but 
> certainly not be setuid root.

Of course, you are right. But it doesn't really matter. The point is 
that a user sits in front of a program that runs as root, but the user 
is not root. That results in the same implications as a setuid program.

>> It's certainly doable, but not too many people regard it as a welcome 
>> waste of time to implement such a thing and take the blame for any 
>> security issues. Cause if the login manager can be broken, you're fucked 
>> big time.
> 
> as long as the GUI part runs as user nobody and drops all privs you're fine... 
> the only real risk is how to pass the login info to the privilidged daemon in 
> such a way that it doesn't open more holes, but that should be trivial...

Yes, of course. We all know that secure communication between two 
processes is one of most trivial problems in computing.

Let's say you take a pipe, and chmod it so only nobody (and root, of 
course) can read it. So every nobody process can monitor the 
communication, I guess.

If you use a dedicated user,  say xfdm, still every xfdm process can see 
your password. If you say that the GUI is weak and can be broken, a 
previous user of xfdm might have managed to create a process to monitor 
any pipes/sockes of user xfdm. It would have the appropriate rights. Bingo.

So, I'd really go for a private/public key approach that ensures that 
only the holder of the private key (the privileged process) is able to 
decrypt the authentication data. That's why qingy uses ssl for this.


Bye
Tim