Document howt to run XLibre as non-root user

[stefan11111]

Describe the update

Reading through https://github.com/orgs/X11Libre/discussions/61 , it seems like some documentation on running X as a non-root user is needed.

@callmetango Perhaps you can find a good place for this info so it is visible.

The X server needs access to various resources, most notably the screen and input devices.
This is true for any display solution, be it Xorg, Xlibre, tinyX, wayland, or anything else that needs to draw to the screen.

For this, the X server needs to have sufficient permissions to access these resources.
What exactly these resources are depends on the setup.
It might, for example, need read/write access to /dev/dri/card0, /dev/input/mice and /dev/tty7.

The simplest way to give the X server access to all these is to make the X server suid root.
Another simple method is to change the group owning these files to something like xgroup, and making the X server sgid xgroup.

Another popular solution is to hide the permissions in another program that handles the privileged stuff for you, so the X server binary and user don't need any special permissions.
Of the top of my head, some programs that do this are (e)logind, seatd and consolekit(2).

There are just some ways of handling the permissions for the X server. There are probably others.
If someone wants, they could probably use libcap to give the X server the needed permissions.

Some solutions are simpler that others and may use more or fewer dependencies.

Whatever the user/sysadmin chooses, they must choose something.
This is by design. If one could run the privileged operations that the X server needs to run, without being given extra permissions, that would be, by definition, a privilege escalation bug.

Additional Information

No response

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[ajgringo619]

Maybe I'm missing something here. For me, it was as simple as disabling lightdm (Xfce) and starting an xsession manually with startxfce4; basically the same instructions as with my non-XLibre systems.

[smj-cc]

Maybe I'm missing something here. For me, it was as simple as disabling lightdm (Xfce) and starting an xsession manually with startxfce4; basically the same instructions as with my non-XLibre systems.

Perhaps your account is already a member of groups input and video?

The point is that it's become empirically clear that it's not that simple for everyone, hence the need for documentation.

[callmetango]

Yes, I agree that we more than "should" document the different ways to run the Xserver, especially in regard to the privileges needed. Some feedback is exactly about this, and some users repeatedly struggle when setting up resp. running XLibre themselves.

@stefan11111 Thank you for pointing out the different major ways to do so! That is a good start for the documentation. It definitively should go to the Xserver wiki.

[ajgringo619]

Maybe I'm missing something here. For me, it was as simple as disabling lightdm (Xfce) and starting an xsession manually with startxfce4; basically the same instructions as with my non-XLibre systems.

Perhaps your account is already a member of groups input and video?

The point is that it's become empirically clear that it's not that simple for everyone, hence the need for documentation.

Wholeheartedly agree - more docs are always a good thing. I'm not a member of either group, by the way:

uid=1000(ajgringo619) gid=1000(ajgringo619) groups=1000(ajgringo619),3(sys),50(games),108,981(rfkill),998(wheel)

[smj-cc]

I'm not a member of either group, by the way:
uid=1000(ajgringo619) gid=1000(ajgringo619) groups=1000(ajgringo619),3(sys),50(games),108,981(rfkill),998(wheel)

does your account have read/write perms on /dev/dri/* and/or /dev/input/* ?

[ajgringo619]

Only to /dev/dri/renderD128:

$ /bin/ls -Alv /dev/{dri,input}
/dev/dri:
total 0
drwxr-xr-x  2 root root         80 Oct 23 08:51 by-path
crw-rw----+ 1 root video  226,   1 Oct 23 08:52 card1
crw-rw-rw-  1 root render 226, 128 Oct 23 08:51 renderD128

/dev/input:
total 0
drwxr-xr-x 2 root root     360 Oct 23 21:28 by-id
drwxr-xr-x 2 root root     720 Oct 23 21:28 by-path
crw-rw---- 1 root input 13, 64 Oct 23 08:51 event0
crw-rw---- 1 root input 13, 65 Oct 23 08:51 event1
crw-rw---- 1 root input 13, 66 Oct 23 08:51 event2
crw-rw---- 1 root input 13, 67 Oct 23 08:51 event3
crw-rw---- 1 root input 13, 68 Oct 23 08:51 event4
crw-rw---- 1 root input 13, 69 Oct 23 08:51 event5
crw-rw---- 1 root input 13, 70 Oct 23 08:51 event6
crw-rw---- 1 root input 13, 71 Oct 23 08:51 event7
crw-rw---- 1 root input 13, 72 Oct 23 08:51 event8
crw-rw---- 1 root input 13, 73 Oct 23 08:51 event9
crw-rw---- 1 root input 13, 74 Oct 23 08:51 event10
crw-rw---- 1 root input 13, 75 Oct 23 08:51 event11
crw-rw---- 1 root input 13, 76 Oct 23 08:51 event12
crw-rw---- 1 root input 13, 77 Oct 23 08:51 event13
crw-rw---- 1 root input 13, 78 Oct 23 08:51 event14
crw-rw---- 1 root input 13, 79 Oct 23 08:51 event15
crw-rw---- 1 root input 13, 80 Oct 23 08:51 event16
crw-rw---- 1 root input 13, 81 Oct 23 08:51 event17
crw-rw---- 1 root input 13, 82 Oct 23 08:51 event18
crw-rw---- 1 root input 13, 83 Oct 23 08:51 event19
crw-rw---- 1 root input 13, 84 Oct 23 08:51 event20
crw-rw---- 1 root input 13, 85 Oct 23 21:28 event21
crw-rw---- 1 root input 13, 63 Oct 23 08:51 mice
crw-rw---- 1 root input 13, 32 Oct 23 08:51 mouse0
crw-rw---- 1 root input 13, 33 Oct 23 08:51 mouse1

[smj-cc]

I must admit I'm intensely curious to learn why it works... (SUID X?), but I'm reluctant to spam here any longer.

[cepelinas9000]

Only to /dev/dri/renderD128:

$ /bin/ls -Alv /dev/{dri,input}
/dev/dri:
total 0
drwxr-xr-x  2 root root         80 Oct 23 08:51 by-path
crw-rw----+ 1 root video  226,   1 Oct 23 08:52 card1
crw-rw-rw-  1 root render 226, 128 Oct 23 08:51 renderD128

/dev/input:
total 0
drwxr-xr-x 2 root root     360 Oct 23 21:28 by-id
drwxr-xr-x 2 root root     720 Oct 23 21:28 by-path
crw-rw---- 1 root input 13, 64 Oct 23 08:51 event0
crw-rw---- 1 root input 13, 65 Oct 23 08:51 event1
crw-rw---- 1 root input 13, 66 Oct 23 08:51 event2
crw-rw---- 1 root input 13, 67 Oct 23 08:51 event3
crw-rw---- 1 root input 13, 68 Oct 23 08:51 event4
crw-rw---- 1 root input 13, 69 Oct 23 08:51 event5
crw-rw---- 1 root input 13, 70 Oct 23 08:51 event6
crw-rw---- 1 root input 13, 71 Oct 23 08:51 event7
crw-rw---- 1 root input 13, 72 Oct 23 08:51 event8
crw-rw---- 1 root input 13, 73 Oct 23 08:51 event9
crw-rw---- 1 root input 13, 74 Oct 23 08:51 event10
crw-rw---- 1 root input 13, 75 Oct 23 08:51 event11
crw-rw---- 1 root input 13, 76 Oct 23 08:51 event12
crw-rw---- 1 root input 13, 77 Oct 23 08:51 event13
crw-rw---- 1 root input 13, 78 Oct 23 08:51 event14
crw-rw---- 1 root input 13, 79 Oct 23 08:51 event15
crw-rw---- 1 root input 13, 80 Oct 23 08:51 event16
crw-rw---- 1 root input 13, 81 Oct 23 08:51 event17
crw-rw---- 1 root input 13, 82 Oct 23 08:51 event18
crw-rw---- 1 root input 13, 83 Oct 23 08:51 event19
crw-rw---- 1 root input 13, 84 Oct 23 08:51 event20
crw-rw---- 1 root input 13, 85 Oct 23 21:28 event21
crw-rw---- 1 root input 13, 63 Oct 23 08:51 mice
crw-rw---- 1 root input 13, 32 Oct 23 08:51 mouse0
crw-rw---- 1 root input 13, 33 Oct 23 08:51 mouse1

you have crw-rw----+ 1 root video 226, 1 Oct 23 08:52 card1, + means there is acl here set by polkit/udev (I'm not confident which one sets).

You can get aditional permision with getfacl, like

$ getfacl /dev/dri/card0
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
user:ajgringo619:rw-
group::rw-
mask::rw-
other::---

[ajgringo619]

Good catch! No SUID on /usr/bin/Xorg, by the way:

$ getfacl /dev/dri/card1 
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card1
# owner: root
# group: video
user::rw-
user:ajgringo619:rw-
group::rw-
mask::rw-
other::---

I believe this is being set by udev, but I'm not well-versed in how it works. The change is definitely happening after console login.

[smj-cc]

interesting... I have some studying to do on acls. One of those things I never got around to, like nftables... until I did, and wished I'd done it sooner. nftables rock, almost a programming language.

[stefan11111]

Reading these ports, it seems like my point is still being missed.
The point I tried to make with this is that, while each solution has its advantages and disadvantages, you have to use a solution. You can try to minimize the privileges the X server has, but you still have to give it extra privileges one way or another.

Take a file like /dev/dri/card0, which you don't want every program run by your user to have access to.
One way to give the X server access to this is suid/sgid.

Another one is to have a small program that runs with root privileges and executes privileged commends on behalf of the X server.
At first glance, the latter might seem more secure, but is it really?
If the small root-privileged program executes any command the X server sends to it, then does it really matter that the X server binary doesn't itself have extra privileges?

One way or another, you have to give the X server extra privileges. Whether that's via classic suid/sgid, or via some other mechanism that hides the effective privileges for the X binary from you, the privileges are still there.

For those familiar with math, a more clear example might be:
Let A be a finite ring with no 0 divisors vs Let A be a finite field.

While it is obvious that the second statement implies the first, and the first statement seems weaker than the second statement, they are in fact equivalent.

Same thing happens here. Does it really matter if an attacker somehow exploits me and uses my privileges to inflict harm on the system vs if an attacker exploits me, a non-privileged process and makes me order a privileged process to inflict harm on the system on my behalf?

[smj-cc]

My objective is to confine the privilege to an easily auditable section of code. If that code simply executes whatever it's told, that's not confining the privilege, and that should be obvious to an auditor. When the privilege is available to all of the X code, even if not all of it (presently) makes use of the privilege, that's not easily auditable.

It seems to me that privilege is needed only for rare events, like opening devices on startup or switching consoles. The process could therefore be made extremely auditable (and modifiable) by scripting it, provided that a reasonably secure scripting language is employed. (not bash)

If this code were stable, it would be best to code it in C but, security is always a "cat and mouse" game. No security is "stable".

As an easy compromise, it seems far less "risky" to me to allow everything I personally deign to run as my user full access to my audio/video hardware, than to allow all X11 code full access to the power of "root".

Better, would be to only allow all X11 code full access to my audio/video hardware. So I'm leaning toward running X as a unique user/group. I'm clearly not the most qualified to assess these issues as they relate to X, but those who are, have historically been fine giving full root privilege to all X11 code, so it has seemed in past that I was on my own.