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."
Confused article. (Score:5, Insightful)
Linux's SUID X server problem has been kind of a "dirty little secret" for many years. Most modern distributions include a few crude workarounds, such as dimming the display and then freezing X whenever the user is asked to type in a root password. Getting rid of the SUID bit altogether ought to make netbooks powered by Moblin technology much more difficult to snoop on over the network.
This does not make sense. Graphical sudo wrappers have nothing to do with X being suid, and neither does anything to do with network traffic.
It seems likely that with NRX technology, you could run X apps over a network with much less risk to the app server (the system that runs the "X client" component, in the backwards terminology of X).
This is actually backwards, the only place there's less risk is for the system that the X server is running on.
Correct me if im wrong (Score:2, Insightful)
But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....
Re:frost nixon (Score:5, Insightful)
Graphics drivers (Score:5, Insightful)
If graphics drivers were implemented in the kernel instead of the X server, this problem wouldn't have existed in the first place.
Re:Stupid (Score:3, Insightful)
> Yeah, the submitter is clearly clueless as is timothy since he couldn't notice such a glaring error.
Well the Slashdot editors went to the Grey Side (Mac) a decade ago so what the hell would they know about X. The /. servers are still *NIX so they know and care about that side a bit.
> Which basically makes it harder for someone to get root access since they have to find another exploit to gain it.
Sure, this move is a win for security because X was big complicated and running as root, but not cause for great rejoicing as at any point in time there is usually an unpatched local root exploit or two out in the underworld. We really need to worry more about security before we start hitting the lamestream media every few weeks..
Re:Two questions: (Score:4, Insightful)
1. Does this mean you can't login at a graphical interface? I.e. will you have to login at a terminal and then wait for X server to come up?
No. There should be a login X server (running as root or nobody or whatever) to display GDM, then during login this server will exit and launch a new server under your uid. Or something like that.
2. If multiple users login, will each user get their own instance of X server? This seems like overkill...
I think fast user switching already works that way. We don't consider it overkill that each user gets their own instance of Firefox; why is X any different?
Re:One of the shortcommings in security (Score:3, Insightful)
How big of a security problem was this? I haven't seen a linux system with open ports for X in 10 years. Anyone who wants to use remote X just uses ssh -X, it's easier to set up than xhost anyway.
Re:Graphics drivers (Score:3, Insightful)
If graphics drivers were implemented in the kernel instead of X, you would have to write new drivers for every kernel you want to run X on.
Re:Graphics drivers (Score:3, Insightful)
We have that situation for all other drivers and somehow we survived. Also, it's common for vendors to write a single BSD-licensed driver and then port it to multiple OSes, sharing most of the code.
Re:IMHO (Score:3, Insightful)
Yes, DRI access is done through /dev/dri* and works correctly.
Re:Graphics drivers (Score:3, Insightful)
What has changed?
The fanatics have become more reasonable?
Re:Have you used Moblin? (Score:5, Insightful)
Its very flashy and friendly if all you do is check your email and browse the web though.
Almost like that was the entire point of the distro in the first place!
Re:frost nixon (Score:5, Insightful)
Re:X Hosting? (Score:3, Insightful)
> I'm not sure I grasp the concept of X Hosting, and how this non-SUID server would help
> that.
It wouldn't. The author of the article hasn't the foggiest notion of how X works (well, he does have a foggy notion, but it's wrong). The machine(s) running the client(s) run only the client code and run it as the user.
Re:Is this right ? (Score:3, Insightful)
I am not sure that this is the right solution. Not running it as root is good, but running it as me - I don't know. I'd rather that the user that runneth the X server is some sort of 'xserver' user - to whose process I connect. That 'xserver' user then has the right to push my screen into VGA mode and all that.
As another poster mentioned, this makes multi-user X a bit more difficult. What's the issue of having your user ID doing all this? If you're allowed to log into the console, then you're presumably allowed to run X (or not; you can still lock down the machine so particular users can't run X or access the graphics hardware). If you can run X, you can talk to the graphics hardware. Note that this doesn't give you carte-blanche to fiddle with the graphics card's registers to try to make the machine crash: you only get certain actions as provided by the DRI interface.
Also, this doesn't fix all those other services (that gnome has, for example) that allow my X programs to mount stuff etc. Which is, again, a security risk by itself.
No, you just don't understand how it works. X apps do not mount things. HAL (or, soon, DeviceKit-disks) mounts things on behalf of authenticated requests from X apps (or console apps, even). HAL/DeviceKit are system daemons that have no GUI. Frameworks like PolicyKit and ConsoleKit ensure that you aren't mounting or unmounting things you shouldn't be.
Re:Graphics drivers (Score:5, Insightful)
Re:Remote X servers? (Score:5, Insightful)
Re:X Hosting? (Score:4, Insightful)
I don't know... (Score:3, Insightful)
Certainly this isn't worse than the current situation. But if my data is still at risk I have a hard time caring much about any "security" advantage.
Without my data the machine is worse than worthless.
Re:Is this right ? (Score:3, Insightful)
What's the issue of having your user ID doing all this?
A remote hole in a process run as 'nobody' allows some log files to be trashed, maybe.
A remote hole in a process run as me allows all of my data to be destroyed.
Why not take it one step further? (Score:3, Insightful)
Does graphics mode switching inside the kernel mean that we can soon expect switching between VTs to work even if the X server is locked up? Or is the keyboard handling still going to prevent that? (Doing the switching from a remote login would work around the keyboard issue).