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 16:42, Jakub Piotr CÅ‚apa wrote:
> 
>>Sean Middleditch wrote:
> 
>>>It's impossible to stop users from running code.  If nothing else, you
>>>can manually run ld-so with your binary as input.  Other than using
>>>something like SELinux, which even then (given how sickeningly complex
>>>it is for even its creators to configure properly on multi-purpose
>>>machines) will likely have many holes.
>>
>>So -o noexec is only syntactic sugar?
> 
> For the most part.  It's deterrent.  With noexec, trying to directly
> execute a binary (using exec() and such, through the kernel) will be
> disabled.  There's very many other ways to start a new process from an
> arbitrary binary, however.

I suspected sth like that when I encountered noexec for the first time 
but never actually managed to check myself or google for it. I guess 
I've believed that it is somehow made secure and noexec is not only 
about making things a little more difficult. ;)

>>>>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.
>>>
>>>Nope.  I can switch to a text console and write a script that launches a
>>>new X session with my fake login program in a loop.  kill the X server,
>>>the script just relaunches it.  Again, no way to tell if it's my hack or
>>>the real login server.
>>
>>So don't allow running random garbage on different virtual consoles. 
> 
> It's a useful feature.  If security axes half the things that we use
> Linux/UNIX for, why bother using such an OS at all?

Not half. What is so useful in being able to spawn a process on a new 
vt? (remember - it would be configurable and such strict policies would 
only be needed on ~1% of machines, those which can be somehow accessed 
by many different and not necessarily trusting each other people)

>>>>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)
>>>
>>>And then we have a minor security hole in that a user can switch to some
>>>console another user might be using (but have locked) and kill
>>>everything running there.  (And, before you ask, it is possible to turn
>>>off the ctrl-alt-backspace to protect against this as well.)
>>
>>And how does that differ from your proposal? Ctrl-Alt-Del to kill 
>>everything and get a login screen? If we change this to open a new login 
> 
> When did I say to kill anything?  You added the "kill everything" part
> on your own.  ;-)

It was an obvious way to get the real login screen. The other ways of 
doing this I thought of were also mentioned but all of them suck IMHO. 
So - Yes, I understand the problem and the need of fixing it - No, I 
don't really like the proposed solution but I can't find a better one by 
myself.

>>screen every time we have a simple DoS attack and if we set some maximum 
>>number of open consoles we get back to the begining (just made a little 
>>more difficult).
> 
> This may be why they are considering putting the login into the kernel
> itself (although I believe it's possible to find another solution). 
> With the login in the kernel, the kernel knows that the current VT is
> indeed the real login manager, and doesn't need to allocate a new VT. 
> It could also remember which VT already has a login console, and just
> switch to that from the current VT when ctrl-alt-del is pressed.

And what do we do whan we run out of virtual consoles? If somebody logs 
in many times and sets a false login screen on every virtual console the 
user will just get irritated that TheMagickKeySequence is not working 
and enter his password in the first textbox he finds...

> I'm sure it's possible to do this with out-of-kernel processes, but I'm
> not a big-time kernel-buff to say for sure.  Arguing with me instead of
> the people who are actually working on the login system and planning on
> bringing it up at the Kernel Summit isn't going to answer that one. ;-)

I don't feel like arguing. I'm rather trying to find a best solution. 
(and adding any hardcoded login screen into the kernel is *not* a good 
idea in my opinion; ti's the policy-mechanism thing I suppose)

This list is the first place I've encountered this kernel login screen 
idea and probably that's why we are discussing it here. ;)

> I'd imagine though that it's possible for the kernel to know that it
> spawned process X on the VT, and if it's the same process owning the VT,
> then it's a safe login console.
> 
> I should also note that most systems already allow users to create a
> whole bunch of login consoles by using things like gdmflexiserver and
> the like.  There are a maximum number of VTs, and if you allocate a new
> login console on each (assuming login console processes are insane
> resource hogs), you can't really DoS the service.  It's not like having
> three unused login consoles is going to stop someone from logging in. 
> Multiple active logins are actually a good thing.  ;-)

I know. I have two permanent X servers on two vts myself. :) The problem 
with vt limit is that the malicious user can take over all of them and 
then the magic key won't work anymore.

Two possible solutions:

1. Use the keyboard swithced to a different mode as you would use a 
special login device. Make TMKS (TheMagicKeySequence) switch the 
keyboard to a special mode in which only uid 0 processes can use it. On 
a non login vt the keystrokes would be captured by the parent process 
(the one that spawned all user processes - probably the login manager) 
and ignored (a warning box could be shown). On a login vt the keystrokes 
would be captured by the login program (which must run as root whether 
we like it or not).

2. Let TMKS kill the X server running on the vt (or any other process 
attached to it) but rewrite GTK and Qt to allow apps to stay alive after 
loosing the connection to the X server. Next time the user logs in he 
would broadcast a DBUS message to all his running processes with the 
info about the new X server he wants them to connect to. Even if not for 
solving the login problem, it would rock anyway. Keith Packard (with Jim 
Gettys) in "The (Re)Architecture of the X Window System" states that it 
ought to be possible and dying upon connection loss is simply a huge and 
stupid bug in the toolkits. Of course this is true only if I understood 
correctly. ;) However, after reading this text, I feel it is doable and 
even not so difficult.

-- 
Regards,
Jakub Piotr Cłapa