Xserver needs to run as "root" on Linux / was: Re: [Xorg] Server side widgets

[Jakub Piotr Cłapa]

Sean Middleditch wrote:
> On Tue, 2004-07-13 at 09:53, Jakub Piotr CÅ‚apa wrote:
> 
>>Jon Smirl wrote:
> 
>>>The idea of a kernel based login is that it is completely secure and
>>>can't be trojaned. A key that can't be intercepted is used to trigger
>>>login. The kernel catches this and clears/draws the screen in a way
>>>that can't be stopped. The keyboard is then directly read for the login
>>>data.
>>
>>Looks really Windowish (and fishy) to me...
>>
>>Why is this better than x/g/w/xdm? AFAIR from the beggining Unixes used 
> 
> I log in.  I make a program that paints a full-screen window identical
> to GDM, but it takes the user names/passwords and mails them to me.  A
> user sits down, tries to log in, and poof, I stole their login
> information.
> 
> This is why Windows has the "Push ctrl-alt-delete to login" window on
> most corporate workstations.  The kernel and _only_ the kernel can catch
> and process ctrl-alt-delete.
> 
> I'm not at all convinced that the actual login screen and daemon needs
> to be in the kernel at all, but there does need to be a way to 100%
> guarantee that you are at the real login screen; kernel-level checks
> using a kernel-only key sequence is one way to do this.  Perhaps the
> kernel can, upon receiving the key-combination, open a new VT and launch
> a specific binary (GDM/KDM/etc) on it?  The only way to trojan that
> would be to over-write the login manager binaries or somehow get access
> to control a VT owned by root/login-manager-user, which shouldn't be any
> easier than cracking the kernel login system, no?

Thanks for explaining this. I think I understand now. :)

Some random thoughts:

What if somebody writes a local exploit? On what systems exposed to such 
malicious users you allow them to run their own code? (ok... you could 
possibly mimic the login screen in flash or sth. like that...)

What's wrong with currently available Ctrl-Alt-Backspace? It would kill 
such a malicious session and you will be sure the thing that shows up on 
the screen is same thing somebody with root access have set.

Basically we need something to kill everything that is running on the 
current virtual terminal and respawn whatever there should be - thats a 
better overall sollution. (it would probably require login managers to 
be spawned by init and not allocating consoles by themselves, but that 
could be a good idea anyway)

Of course the problem is nonexistant if we login with some kind of a 
token (or any other device used only to log in i.e. innaccessible to 
nonroot programs).

-- 
Regards,
Jakub Piotr Cłapa