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

[Sean Middleditch]

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.

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

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

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

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'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.  ;-)
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.