Moblin Will Run X Server As Logged-In User, Not Root 205
nerdyH writes "An architect of the Moblin Project has announced that Moblin 2.0 for netbooks and nettops is the first Linux distribution to run the X server as the logged-in user, rather than SUID'd to root. The fix to this decades-old security liability comes thanks to 'NRX' (No-root X) technology reportedly developed by Intel, Red Hat, and others in the X community, and the Moblin-sponsored 'Secure X' project. Besides making Linux netbooks a lot more snoop-proof, it seems like this could lead to an X-hosting renaissance of sorts, since you wouldn't be risking the whole system just to open up a specific user's account to remote X servers."
X Hosting? (Score:4, Informative)
I'm not sure I grasp the concept of X Hosting, and how this non-SUID server would help that.
X is not required to be running on the remote system for X11 forwarding over SSH. Even running an Xvnc server doesn't require it to be SUID. This seems to be entirely a local security gain for users who will be interacting with local graphics hardware.
Re:One of the shortcommings in security (Score:5, Informative)
I don't know how they've done it, but I know this is a good thing.
They've done it by removing the responsibility of X talking directly to the graphics hardware by implementing Kernel Mode Switching for graphics drivers (among other much needed overhauls to the Linux graphics stack). Thus X can now access what it needs at the logged-in users' level and doesn't need root.
Poor understanding of X (Score:5, Informative)
The article repeats the common misunderstanding: "in the backwards terminology of X"
What exactly is backwards about this? X is the server, and the apps are clients.
Think about it: The client initiates the conversation with the server. The client tells the server what to do.
How is this backwards?
Re:One of the shortcommings in security (Score:5, Informative)
Just got fixed by this. To be honest, I don't know how they've done it, but I know this is a good thing. This will make X and linux more secure and I can only applaud that.
I think what is basically boils down to, is that instead of X talking to the hardware directly it now talks to a file under /dev/ just like everything else.
Stupid (Score:4, Informative)
> it seems like this could lead to an X-hosting renaissance of sorts,
> since you wouldn't be risking the whole system just to open up a
> specific user's account to remote X servers.
What a clueless statement. Somebody doesn't understand how X works. The server part that runs SUID root has never ran on the app server.
What this does do is stop a random remote app getting to root on your workstation but any local exploit of the X server gets them your user account and that can cause a lot of mischief and only needs a different local root exploit to get the rest of the way to 0wn1ng your local desktop machine.
Remote X servers? (Score:4, Informative)
Re:IMHO (Score:5, Informative)
> Can someone spare me reading the article and let me know if DRI is still possible without root?
Yup, this whole thing rests on the new kernel modesetting. That was the last thing that required root to be able to directly frob bits on the video card. DRI also goes into the kernel as it should. The kernel is supposed to own all of the hardware and expose safe APIs for user apps to access it. For historical reasons video has been the exception to that rule. No longer.
Re:Poor understanding of X (Score:5, Informative)
How is this backwards?
It's only backwards in human thought, because people have the ingrained presupposition that the server is the Big Machine In Another Room, and the client is the Little Machine On Your Desk.
Re:Remote X servers? (Score:4, Informative)
It's not just the submitter. Apparently the writer of the blog post themselves don't even understand X all that well.
Re:Correct me if im wrong (Score:5, Informative)
The X server is the program on the local machine that displays the pixels.
The program you run on some other system via the net is the client, even if the thing it's running on is called a server.
The X server traditionally runs as root. You are likely unaware of this because it's started automatically as part of the init process.
The X server running as root is independent of whether the X client is running as root.
Re:Remote X servers? (Score:4, Informative)
The "X server" runs on the machine with the keyboard, mouse, and display. An "X client" is a program (e.g., xterm) that connects to an "X server" to which it sends drawing commands and from which it receives mouse and keyboard events. In the "writing network software sense," these names make sense, because it is the "X server" that sits and listens on a port, and the "X clients" that connect to it. What makes this confusing is that in practice an "X server" will usually run on a user's machine (which you would normally call a 'client') and an "X client" will run on a big machine elsewhere (which you would normally call a 'server'). The problem comes from using the words "client" and "server" to describe both programs and machines; basically, our jargon sucks.
Have you used Moblin? (Score:5, Informative)
Re:One of the shortcommings in security (Score:3, Informative)
But yes, true -- any exploitable flaw in the X server itself (or any of the extensions compiled into or loaded dynamically by the server) could result in root access.
Re:IMHO (Score:5, Informative)
> Sounds like Windows NT 3.5, wonder if it will get moved back into kernel
> space for performance reasons just like NT4 moved video back into kernel space.
Not the same thing. The video hardware belongs in the kernel in exactly the same way as sound, mass storage and the keyboard/mouse do. *NIX and Windows are now alike in that and it is good.
What Windows did was bring most of the next layer up the chain into kernel space. This would be more like putting the whole X server and bits of GTK and/or Qt into the kernel, not just running it as root. Yes it improved performance some, but the security implications are horrific.
Re:Poor understanding of X (Score:1, Informative)
Uh, no. Clients request services from servers; servers host services to clients.
That's what it has always meant, whether you mean a program or a box. The problem is not "using language the way the rest of the world does," the problem is people not understanding what they're talking about.
Re:frost nixon (Score:1, Informative)
Re:Remote X servers? (Score:1, Informative)
Uh, what do you think, exactly, the 'd' in httpd [apache.org], nntpd [cmu.edu] and ircd [funet.fi] stands for?
Comment removed (Score:3, Informative)
Re:frost nixon (Score:1, Informative)
Windows in fact runs (almost) nothing at all as "Administrator". Please find a Windows machine and run Task Manager. There are multiple OS accounts used, like like SYSTEM, LOCAL SERVICE and NETWORK SERVICE, so unlike root on Unix these are shielded from each other and from parts of the system they have no business dealing in. And furthyermore, important parts of the windowing system are implemented as DLLs (shared libraries). Those are run in your process space, and thus under your user account.
Re:X Hosting? (Score:3, Informative)
Ive used X over network connections and I know this to be incorrect, at least over a ethernet. THere are also solutions avialable for the problems you mention, or which can be addressed. There are various products that will compress the X data stream so that it uses less bandwidth and can perform quite acceptably. Such as NX. There was for a while a provide called xmove which was an X proxy to which your X clients would connect, you can send xmove command to redirect the display of the X client between different X servers, allowing your X programs to be moved between X servers. The code is out of date but it would be a useful thing to have that sort of capability and would strengthen X as a remote desktop solution. X is actually a very successful and well performing system and is a very well designed graphics system that actually exceeds windows in capability.