Forgot your password?
typodupeerror
X GUI Security Software Linux

Moblin Will Run X Server As Logged-In User, Not Root 205

Posted by timothy
from the such-a-little-thing-makes-such-a-big-difference dept.
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."
This discussion has been archived. No new comments can be posted.

Moblin Will Run X Server As Logged-In User, Not Root

Comments Filter:
  • by rodgster (671476)

    This is something that is long overdue.

    • Ya think? X is older than I am.

      Can someone spare me reading the article and let me know if DRI is still possible without root?

      • Re:IMHO (Score:5, Informative)

        by jmorris42 (1458) * <jmorris.beau@org> on Thursday July 09, 2009 @05:12PM (#28642309)

        > 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: (Score:3, Interesting)

          by afidel (530433)
          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.
          • Re:IMHO (Score:5, Informative)

            by jmorris42 (1458) * <jmorris.beau@org> on Thursday July 09, 2009 @06:25PM (#28643417)

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

          • by multi io (640409)

            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.

            No, NT4 moved hardware-independent stuff like the GDI and the window system into kernel space, where it doesn't really belong. The hardware-specific video card drivers were always in kernel space, where they do belong.

            In X, hardware-independent stuff like window managers and widget sets ran in user space, where they do belong, while the hardware-specific video card drivers also ran in user space, where they don't really belong.

            Pick your poison.

      • Re:IMHO (Score:4, Interesting)

        by Enleth (947766) <enleth@enleth.com> on Thursday July 09, 2009 @05:13PM (#28642327) Homepage

        Er, the same way USB was for years? Actually, DRI, too. The driver exposes a pseudo-device in /dev/, which actually is a socket-like, high-throughput mmap wrapper and the X server opens it. Given appropriate file permissions and group membership, this can be done from a user account.

      • Re: (Score:3, Insightful)

        by sofar (317980)

        Yes, DRI access is done through /dev/dri* and works correctly.

  • Confused article. (Score:5, Insightful)

    by Timothy Brownawell (627747) <tbrownaw@prjek.net> on Thursday July 09, 2009 @05:04PM (#28642227) Homepage Journal

    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.

  • X Hosting? (Score:4, Informative)

    by Microlith (54737) on Thursday July 09, 2009 @05:05PM (#28642231)

    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: (Score:3, Insightful)

      by John Hasler (414242)

      > 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:X Hosting? (Score:4, Insightful)

        by timeOday (582209) on Thursday July 09, 2009 @08:36PM (#28644763)
        Besides, X, although designed explicitly from the beginning to host remote applications, sucks at it. It is unusable on a link with any significant latency, and cannot migrate a client to a new server. VNC and Remote Desktop, though seemingly less elegant solutions, work much better, mainly because they are synchronized more loosely.
        • Re: (Score:3, Informative)

          by Eravnrekaree (467752)

          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 diff

    • by ls671 (1122017) *

      > This seems to be entirely a local security gain for users who will be interacting with local graphics hardware.

      correct !!!

  • by Anonymous Coward

    But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....

    • by metamatic (202216) on Thursday July 09, 2009 @05:20PM (#28642451) Homepage Journal

      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.

      • by Lennie (16154)

        "The X server traditionally runs as root. You are likely unaware of this because it's started automatically as part of the init process." On many systems it's started by init, but that's not the reason it has root, it has root because the X-binary has setuid bits set.

        • by Alex Belits (437) *

          Actually on any modern desktop/workstation running X it's possible to remove setuid bit from X server, and everything will continue working because X server is started by display manager (usually gdm) running as root. Setuid /usr/bin/Xorg exists entirely for convenience of the users who log in at the console, then run xinit (all five of them).

    • by ls671 (1122017) *

      > But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....

      entirely correct, the X server is the component talking to the video card.

  • by Anonymous Coward on Thursday July 09, 2009 @05:07PM (#28642245)

    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?

    • by Nutria (679911) on Thursday July 09, 2009 @05:13PM (#28642337)

      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.

    • It's backwards because the client applications run on the server, and the server runs on the client machine.
    • by rdebath (884132)

      For the way that X works it's correct.

      But, X is the wrong way around, you should have a client running on the local machine that connects to the remote machine and provides it with a remote display. Like telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows or "ssh -X"!

      In fact X is that ONLY one that puts the server next to the display with the security implications inherent in that.

  • Stupid (Score:4, Informative)

    by jmorris42 (1458) * <jmorris.beau@org> on Thursday July 09, 2009 @05:09PM (#28642283)

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

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

      Yeah, the submitter is clearly clueless as is timothy since he couldn't notice such a glaring error.

      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

      Which is far less dangerous than them getting root access.

      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.

      Which basically makes it harder for someone to get root access since they have to find another exploit to gain it.

      • Re: (Score:3, Insightful)

        by jmorris42 (1458) *

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

        • You can run X on OS X (I do) and it doesn't need root because it runs on top of a window server (which does run as root) that talks to the hardware. The Apple X11 implementation is not the best (it's based on an old version of X.org) but it's capable of running Xephyr if you need more features.
    • Except on any decent Linux distribution, the X server is running inside SELinux and is really not capable of doing much at all.

  • Remote X servers? (Score:4, Informative)

    by TerranFury (726743) on Thursday July 09, 2009 @05:09PM (#28642289)
    I am a bit confused by the submitter's comment about remote X servers. I understand the appeal of remote X clients: I can, e.g., log into a big fast machine and run MATLAB (the X client) there while interacting with the window on my less-powerful laptop (which runs the X server). But what's the point of a remote X server? Why would anyone want to run an X server (software sense of 'server') on a server (hardware sense of 'server')?
    • by j_sp_r (656354)

      You don't need X for Matlab. The interface isn't that good.

      • You don't need X for Matlab. The interface isn't that good.

        It's for plots that having X is useful.

        • I just generate output graphics as files and open them on my machine over sftp. A whole X session seems like monstrous overhead for a transaction that is 99% text and an occasional image file.
          • Hmm... What that lacks is the ability to interact with the plots (zoom in, etc), which I like sometimes... but on the plus side, as you said the overhead is lower, and also 'screen' will work (whereas the equivalent for X clients, 'xmove,' doesn't play nice with xauth, and anyway is rarely installed on servers to begin with).

            A third method that a friend of mine uses (for very big jobs) is to have the MATLAB script generate emails; he just runs it with nohup and logs out.

          • It depends on what you're doing with matlab. If you're just futzing around with things, then you're not writing scripts, you're using the command line and checking what the equations look like every three or four lines of code. I'd say this covers at least 60% of undergrad student usage of matlab, which is likely the most common version, since the student version comes in at under $100 and the real version could be up in the thousands depending on what toolboxes you get. Otherwise octave would be a lot m

    • I doubt I know enough to answer your question, but your question itself confuses me. You understand why someone would want to run "remote X clients", but you don't understand why someone would want to run "remote X servers". If you don't have a server, then who is the client connecting to?

      • Re:Remote X servers? (Score:4, Informative)

        by TerranFury (726743) on Thursday July 09, 2009 @05:55PM (#28643003)

        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.

        • What makes this even more confusing is the role of SSH (when it is used), so that servers and clients are actually connected via other proxy servers and clients running locally...
        • by smoker2 (750216)
          No more confusing than running a web server on your local machine. You can connect to it using localhost, and see the same things others can see if you open the firewall, and expose that service. X is a server, whether you choose to expose it to the outside world is up to you. But just calling it a server alerts you to the possibilities, and gives an idea of how it works. Remember *nix was designed to be a networked system. There was a time when the X server would be on another machine. It is still capable
    • by stevied (169) *
      It's a truism: those who do not understand technology are destined to write clueless articles about it, apparently.*

      Sorry, feeling particularly bitter and twisted this evening ..

      (* or get appointed CTO)
    • A remote X-server is what runs the video wall. I can run the client program on my workstation and have it display on the wall.

      Now, I just need to install the video wall in my underground lair.

  • Graphics drivers (Score:5, Insightful)

    by Chemisor (97276) on Thursday July 09, 2009 @05:19PM (#28642433)

    If graphics drivers were implemented in the kernel instead of the X server, this problem wouldn't have existed in the first place.

    • Re:Graphics drivers (Score:4, Interesting)

      by Wesley Felter (138342) <wesley@felter.org> on Thursday July 09, 2009 @05:29PM (#28642609) Homepage

      Yes, it's interesting that KGI was rejected 10 years ago, but now we have KMS. What has changed?

      • by sofar (317980)

        KGI replaces X, KMS only implements the hardware-specific parts in the kernel, while keeping the entire Xorg userspace (the real "graphics" parts) in userspace.

      • Re: (Score:3, Insightful)

        What has changed?

        The fanatics have become more reasonable?

      • by stevied (169) *
        Linus isn't perfect. His opinions evolve over time. On the whole, though, his intuitive sense of taste has been for Linux, I reckon.

        Also, I think KGI wanted to push a lot more into kernel space that we have now, even with kernel mode-setting, though my aging memory may well fail me..
        • Re: (Score:3, Funny)

          by Anonymous Coward

          Linus isn't perfect

          I met Linus in person a while back and asked him about this. He disagrees with you.

          Since he's perfect, I kinda have to go with him on this one.

        • by stevied (169) *
          On the whole, though, his intuitive sense of taste has been for Linux

          s/been/been pretty good/

          Proof-reading ability falls off with increasing blood alcohol levels, sadly ..
      • by kelnos (564113)
        What, people aren't allowed to change their minds about something given 10 years of new information?
      • by TheRaven64 (641858) on Thursday July 09, 2009 @06:39PM (#28643613) Journal
        KGI was a massively-complicated API which failed to actually expose the useful features of the hardware, while KMS allows the same userspace device drivers (with a small amount of kernel-mode validation, for example of DMA requests) that X11 already uses but removes the need for X11 to be run as root and makes virtual terminals and power saving play nicely with X11.
    • Re: (Score:3, Insightful)

      by Hatta (162192) *

      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: (Score:3, Insightful)

        by Wesley Felter (138342)

        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.

      • Funny how somebody has to write network card drivers for every OS your browser runs on. It's a wonder why nobody has considered putting those drivers in the browser instead.

        • Take a look at the drivers for a simple network card and a simple GPU. Even something like the i830 is a couple of orders of magnitude more complex than something like a RTL8139 network interface.
      • by kelnos (564113)
        That's already been the case for the more mainstream cards (nvidia, AMD, Intel) for many years now. They all require a kernel piece for 3D support. nvidia, at least, has a single driver core that they use for multiple OSes, with a little translation layer for the particular kernel. I don't know what the others do.
    • by bXTr (123510)
      That would be great if you're running Linux, but not *BSD or *nix. People seem to forget that X is not a Linux-only application.
  • Is this right ? (Score:5, Interesting)

    by bytesex (112972) on Thursday July 09, 2009 @05:31PM (#28642641) Homepage

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

    • by drsmithy (35869)

      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.

      So if you have multiple users on the same machine running X, they can stomp on each other (by virtue of all interacting with the same "xserver user") ?

      • by Lennie (16154)

        I guess we all need xusername users so everyone has a seperate user to run X. ;-)

    • by stevied (169) *
      I don't see the problem, to be honest. the toolkit libraries of your apps (by definition running as you) turn requests for widgets into drawing primitives and pixels that need setting in a framebuffer. The X server draws them / sets them. What's the third level of protection protecting you against? Processes memory contents are already protected against each other, the worst the X server might be tricked into doing is reporting the window or clipboard contents of one app to another, which is usually somethi
      • Re: (Score:3, Informative)

        by Ash-Fox (726320)

        It prevents any exploits for the xserver user from being able to effect the rest of the system outside of the confines of the user and whatever it can interface with graphically. Thus preventing it from gaining control to the rest of the system easily. Plus, selinux, apparmor can likely be enhanced to enforce the rules upon the xserver in other ways when it is running as a user process.

    • Re: (Score:3, Insightful)

      by kelnos (564113)

      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: y

      • 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: (Score:3, Insightful)

        by drinkypoo (153816)

        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.

  • X is a large, clutterd and complex system that has no business running as root. It is good to see they finally managed to get away from that implementation, even if it adds a bit more complexity.

    • It looks like they have done this by pushing the hard parts into the kernel. I'm not sure this doesn't make security worse.

  • by SlickSlacker (568960) on Thursday July 09, 2009 @06:18PM (#28643319)
    I just loaded it on my Eee PC and it turns the machine into a kiosk. Very unappealing for anyone who actually wants to use their netbook. Its very flashy and friendly if all you do is check your email and browse the web though.
    • by Freetardo Jones (1574733) on Thursday July 09, 2009 @06:22PM (#28643385)

      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!

      • by Tacvek (948259)

        I've not used it, but the following is my understanding based on the website:

        Moblin is designed to support social networking, media viweing/playing, and web browsing.

        Social networking integration is a main point. Update your flicker status from a drop-down panel of the main toolbar.

        For media viewing the system intends to allow to to browse local and remote media, with integration with services like flicker and last.fm.

        I did not see any IM integration in the short introduction video, although it is a fairly

    • by jhfry (829244)

      Since you have tried it, can you answer a couple of questions.

      1 - can you open a shell/terminal window?
      2 - can you create custom application launchers

      If so, how is it so unappealing. Perhaps you just need to customize it a little to make your needs more accessable. If not, then you have saved me the effort of giving it a try.

  • On MacOS X, the X server also runs as the logged-in user. It isn't clear what "nerdyH" means by its last sentence, which doesn't really make a lot of sense. No one who cares about security puts unshielded X Windows sessions on insecure networks, because X Windows data streams between clients (e.g. xterm, Firefox, the Gnome or KDE desktops, or almost anything graphical on any Linux machine) and display servers (the piece that 'serves' a display device to clients) are not encrypted. Remote X Windows sessio
    • Tracking down a bug at work I once downloaded the sources for X11. I can't recall if it was XFree or X.org which I got but what I saw was scary. Its all old school C. Functions trust the array indices they are given. Bounds checking is rarely done. I was eventually able to prove that the code I investigated was correct, but it took a lot of head scratching to get that far.
    • by kasperd (592156)

      On MacOS X, the X server also runs as the logged-in user.

      That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens

  • by kasperd (592156) on Friday July 10, 2009 @06:39AM (#28647567) Homepage Journal
    Since there was never any reason for the X server and the clients to need to use the same uid, why move the X server from root to the logged in user? It could as well be moved from root to a uid dedicated to the X server. Then you would get another level of separation, at essentially no price. (There is of course a caveat in case you have multiple X servers running at the same time, but that could be solved by allocating a uid per X server).

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

A consultant is a person who borrows your watch, tells you what time it is, pockets the watch, and sends you a bill for it.

Working...