User: Password:
|
|
Subscribe / Log in / New account

Where are the non-root X servers?

Where are the non-root X servers?

Posted Sep 9, 2010 6:39 UTC (Thu) by drag (subscriber, #31333)
In reply to: Where are the non-root X servers? by ctpm
Parent article: Where are the non-root X servers?

If your going to do it, you might as well do it right.

------------------------

There are 3 major situations you have to deal with.

1. Typical desktop --- Single user, just give the user's X Server rights to all inputs by default and everything is great.

2. Single seat, Multi User --- multiple users logged in, but only one is active at a time. You give only the active X Server rights to all inputs and deny it to everybody else. When they switch from one X Session to another the rights follow the active one.

3. Multi seat, Multi User --- Multiple users logged in, multiple sessions being used simultaneously. With this you depend on the administrator (privileged user) to manually delegate which X session gets which input.

-----------------------

Really the solution is just very obvious for all 3:

Your going to need a privileged "input proxy" that relays the input via sockets to the correct X Server. Then that proxy decides, probably (optionally) with assistance with packagekit and dbus, to give which user the inputs based on criteria like:
Is the X Session the current one in focus on the machine?
What X Session was given rights to what input by administrator?
I a user already using it?
etc etc.

To make it simple for administrators and users you just serve up input to whatever X session is active first. This is already what behavior people naturally expect anyways.

It's something that should be very lightweight. Just relay the raw input directly to the X Server and let the existing X Server code for auto detecting inputs and such take care of the details. You'd just have to change things around so that instead of reading from multiple file descriptors in /dev/input your reading from sockets in /var/something.


(Log in to post comments)

Where are the non-root X servers?

Posted Sep 9, 2010 6:41 UTC (Thu) by drag (subscriber, #31333) [Link]

> To make it simple for administrators and users you just serve up input to whatever X session is active first.

That is, I mean, by default. You'll have it configurable for multi-seat, multi-user setups.

Where are the non-root X servers?

Posted Sep 9, 2010 6:55 UTC (Thu) by rvfh (subscriber, #31018) [Link]

Are you not just going from 'one X server running as root' to 'one input server running as root'? It does mitigate the problem I suppose, and maybe it's the only way (apart from revoke()), but does it solve it?

Where are the non-root X servers?

Posted Sep 9, 2010 13:02 UTC (Thu) by foom (subscriber, #14868) [Link]

Yes. You have to privileged code handling input, either living in the kernel or in a privileged process. It's possible to write secure code, it's just very hard when you have as much code as the X server does (or...for that matter, the linux kernel, but that's a different issue). If you put the input server in a separate privileged process, you have to secure a lot less code, so the problem becomes feasible.

And note that it doesn't actually have to run as root, just as a priv user.

Where are the non-root X servers?

Posted Sep 9, 2010 23:45 UTC (Thu) by martinfick (subscriber, #4455) [Link]

Additionally, this code would not likely be exposed to nearly the huge attack base that the current X server is exposed to. It would likely only be exposed to the proxied data, and perhaps to some user switching input code, but that is surely a greatly reduced attack vector than the current model.

Where are the non-root X servers?

Posted Sep 13, 2010 21:30 UTC (Mon) by oak (guest, #2786) [Link]

And even that attack surface is reduced if that input daemon doesn't proxy the input, but only tells X which input device to use and on "hot seat" arrangements takes care of switching access rights on the input devices so that only the active X server can access given device at any given time...?

Where are the non-root X servers?

Posted Sep 9, 2010 12:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Maybe we can create 'multiplexed' devices?

For example, we can use CUSE to create a personal set of devices for each user. When X is switched between users, we can connect/disconnect these devices from the real underlying input devices.

Where are the non-root X servers?

Posted Sep 9, 2010 18:27 UTC (Thu) by bronson (subscriber, #4806) [Link]

I was thinking along these lines too. LXC does a good job of giving individual processes their own custom views of system resources. I haven't used it for fine-grained access control yet but, from what I hear, it seems like it would do a good job of isolating X processes and global devices from one another.

Where are the non-root X servers?

Posted Sep 16, 2010 16:26 UTC (Thu) by Wol (guest, #4433) [Link]

I was thinking something like that.

We need a dedicated device driver, then some way of converting that to a file :-) So we can put the "revoke" type code in the device driver (or just above it in HAL or whatever). When a process "opens" the keyboard device, it gets a new file handle from the device driver, which disconnects and leaves any previous file handles hanging (or points them at /dev/zero :-)

Either way, unlike the screen device driver that enforces multiplexed access, the keyboard/mouse/etc drivers enforce simplex access.

Cheers,
Wol

Where are the non-root X servers?

Posted Sep 16, 2010 8:45 UTC (Thu) by NikLi (guest, #66938) [Link]

Right.

In my opinion, on a single-user system (99% of PCs today!), devices like /dev/input/mice and /dev/tty? should be readable by the user and /dev/fb? read/write by the user (as long as it's a local user). It doesn't make any sense to make those devices administrator-only.
(as a matter of fact, locally, I chmod them +rw by the init scripts in order to be able to run linuxfb applications as user)

It did made some sense in the old days because some students with telnet would do stuff like "echo "Teh Admin is BOFH" > /dev/tty0" and that would be printed on the admin's monitor while he was giving a presentation to the board and be very embarassed. But multiuser systems are more rare and their administrators have the knowledge to tune them.

Where are the non-root X servers?

Posted Sep 16, 2010 16:28 UTC (Thu) by Wol (guest, #4433) [Link]

Multi-user systems more rare? Not rare enough! My home system is multi-user - I've got a Phenom X3, and use my old pc as a terminal so both me and my wife can share the main system. I bet there are plenty of systems like that around.

Pretty easy even for a non-BOFH to do ...

Cheers,
Wol

Where are the non-root X servers?

Posted Sep 17, 2010 8:40 UTC (Fri) by NikLi (guest, #66938) [Link]

That is still single user. By "multiuser" i wasn't referring to multiple user processes at the same time but rather a system that gives (mostly remote) access to untrusted users.

In other words, i believe that the user sitting on the desktop should be -by definition- priviledged to use the input/framebuffer devices.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds