non-root xorg static /dev

[stefan11111]

I use Xorg with USE="suid" and do not use elogind.
I remember reading somewhere that USE="suid" is somehow unsecure, so I would like not using it if that's true.
I also do not use elogind.
From my understanding, all USE="suid" does is chmod 4711 /usr/bin/Xorg.
If I chmod 0755 /usr/bin/Xorg or compile x11-base/xorg-server with USE="-suid", I am able to start X.
The keyboard works well, but the mouse does not work.
This happens even it I use startx -- vt1.
I can't see how the mouse is different from the keyboard in this case.
I have tested this with different mice, the result is the same.

[Leonardo.b]

Look into Xorg logs, something alike "permission denied".
Probably you have to adjust some permissions in /dev to access input devices.

[NeddySeagoon]

stefan11111,

I remember reading somewhere that USE="suid" is somehow unsecure, so I would like not using it if that's true.

You need to read that in context. Is it insecure in a way that can actually be exploited on your system?
If it is, do you care?
If potential threats are people you trust, then does it matter to you?

Xorg requires that some of its setup is performed by root, or something running as root. e.g. elogind, systemd ... whatever.
Why would you trust them running as root and not Xorg?

Security depends on evaluating your threats and deploying mitigation measures, not a blanket its insecure how do I fix it?

For the avoidance of doubt, I run a static /dev with Xorg suid. The threat model does not apply to my use case, so II don't mind.
It also has the advantage that I understand the Xorg suid threat. Being old and cynical, I'll suggest that the alternatives are just different, but I don't understand the insecurities that they add so maybe its just prejudice.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

In short, keep it simple.

[stefan11111]

stefan11111,

I remember reading somewhere that USE="suid" is somehow unsecure, so I would like not using it if that's true.

You need to read that in context. Is it insecure in a way that can actually be exploited on your system?
If it is, do you care?
If potential threats are people you trust, then does it matter to you?

As long as an external attacker can't exploit this, I don't really care.
The only thing I'm worried about is some gui app abusing the suid bit.

Xorg requires that some of its setup is performed by root, or something running as root. e.g. elogind, systemd ... whatever.
Why would you trust them running as root and not Xorg?

I sure as hell don't trust anything related to Lennart or systemd with root access. The solution I was looking for was a fix to my xorg.conf or some chmod/chown stuff.
I definitely don't want some program to manage this.

Security depends on evaluating your threats and deploying mitigation measures, not a blanket its insecure how do I fix it?

For the avoidance of doubt, I run a static /dev with Xorg suid. The threat model does not apply to my use case, so II don't mind.
It also has the advantage that I understand the Xorg suid threat. Being old and cynical, I'll suggest that the alternatives are just different, but I don't understand the insecurities that they add so maybe its just prejudice.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

In short, keep it simple.

I design my systems with this in mind.
However, I would still like to know how suid is vulnerable and why is elogind considered safer.

On another note, looking through threads, I see many references to "off the wall". What is that?

[NeddySeagoon]

stefan11111,

I'll leave you to research the Xorg suid threat. You need to read several perspectives on it.

Off the Wall was a forum here several years ago. It was closed.
In response several regulars there set up their own OTW2 but it appears to have failed.

[Leonardo.b]

I read ypu can run no-suid Xorg without logind on OTW20, indeed. I remember Moose wrote something about that.
Sad OTW20 is not up anymore.

[NeddySeagoon]

Leonardo.b,

Your favourite search engine will show you how.

[Anon-E-moose]

The need to be root, was mainly for drm master changing on the tty.
But that was changed somewhere early in the 5.x (flaky memory 5-8 or so), and running as root isn't necessary.
This is all predicated on using something like startx where you would use the -vt switch for whatever console # you are on
(or manually set the perms on tty7 to 660 instead of 600 and be a member of tty group)
I have this as a udev rule

Code: Select all

grep tty /etc/udev/rules.d/*
/etc/udev/rules.d/75-tty-don.rules:SUBSYSTEM=="tty", KERNEL=="tty[7-8]", GROUP="tty", MODE="0660"

If using a dm to start X, then I don't know.

Any way you choose with a modernish kernel, X doesn't need either suid root or using sudo/be root.

[GDH-gentoo]

However, I would still like to know how suid is vulnerable and why is elogind considered safer.

I don't recall a specific vulnerability (those tend to get fixed in version bumps anyway), but I believe this recommendation is just an instance of the more general "don't run complex software as root" recommendation. The reasoning being that the more complex a piece of software gets, the higher the probability of having undetected bugs is. In other words, the first part of Tony Hoare's quote. And Xorg is quite complex.

In comparison, elogind and systemd-logind are much simpler. But:

• I still wouldn't describe elogind and systemd-logind as "simple". For instance, they both have D-Bus client functionality, which is anything but.
• Even if Xorg does not have the set-user-ID on execution permission, display managers run as root, and quite a few spawn an Xorg child that also runs as root anyway.

Any way you choose with a modernish kernel, X doesn't need either suid root or using sudo/be root.

Having elevated privileges (by being root or having a nonprivileged effective user that is a member of groups that it shouldn't be a member of) is still required for other operations, including open() system calls for files in /dev. Others depend on the X11 drivers being used.

[stefan11111]

Looking through other threads, I see that when people try to use xorg without suid or elogind, they don't even get a display.
This is not my case, I get a display and I also can use the keyboard. It's just the mouse that doesn't work.
I tried chmod =660 /dev/tty7, but the problem remains.
I am a member of the tty group.
I use linux 6.2.8-gentoo, so the kernel is modern enough.

[GDH-gentoo]

I use linux 6.2.8-gentoo, so the kernel is modern enough.

And which X11 drivers? Without libudev there's a very limited selection.

[Leonardo.b]

Leonardo.b,

Your favourite search engine will show you how.

My favourite pub closed. I know I can get beer everywhere, it's not about that.

[stefan11111]

And which X11 drivers? Without libudev there's a very limited selection.

I use xf86-input-mouse and xf86-input-keyboard from Neddy's static-gentoo overlay.
Nothing depends on these drivers though.

[GDH-gentoo]

OK, then post Xorg's log. Any insufficient permissions issues should show up there.

[NeddySeagoon]

Leonardo.b,

My main point was that there are several solutions.
Some as bad as the the thing they are supposed to fix.

The way forward, is to make a shortlist and evaluate them in turn.

[stefan11111]

OK, then post Xorg's log. Any insufficient permissions issues should show up there.

Here is my Xorg.0.log:
https://github.com/stefan11111/pastebin ... Xorg.0.log
Here is my xorg.conf:
https://github.com/stefan11111/pastebin ... /xorg.conf

[Leonardo.b]

NeddySeagoon, I understand, that makes sense.

[GDH-gentoo]

Here is my Xorg.0.log:
https://github.com/stefan11111/pastebin ... Xorg.0.log

OK, I don't see any obvious permissions problems there, and xorg.conf looks good to me. Looks like we are in "debug problems with a static /dev" territory...

Answer is probably "yes", but /dev/input/mice exists, rigth?

[NeddySeagoon]

stefan11111,

It that log with Xorg suid or not?

[stefan11111]

stefan11111,

It that log with Xorg suid or not?

Oops, looks like I sent the wrong log, the one with suid.
Here is the good log, the one without suid:
https://github.com/stefan11111/pastebin ... .0.log.new
Yes, /dev/input/mice does exist.

Code: Select all

$ ls -lah /dev/input/mice
crw------- 1 root root 13, 63 Mar  6 10:40 /dev/input/mice

[GDH-gentoo]

Here is the good log, the one without suid:
https://github.com/stefan11111/pastebin ... .0.log.new

Code: Select all

[   220.669] (EE) xf86OpenSerial: Cannot open device /dev/input/mice
	Permission denied.
[   220.669] (EE) Mouse0: cannot open input device

And there you have it.

Code: Select all

$ ls -lah /dev/input/mice
crw------- 1 root root 13, 63 Mar  6 10:40 /dev/input/mice

You have to be root to open /dev/input/mice.

[stefan11111]

Here is the good log, the one without suid:
https://github.com/stefan11111/pastebin ... .0.log.new

Code: Select all

[   220.669] (EE) xf86OpenSerial: Cannot open device /dev/input/mice
	Permission denied.
[   220.669] (EE) Mouse0: cannot open input device

And there you have it.

Code: Select all

$ ls -lah /dev/input/mice
crw------- 1 root root 13, 63 Mar  6 10:40 /dev/input/mice

You have to be root to open /dev/input/mice.

Well, now I feel stupid.
The problem was blindingly obvious.
The fix was:

Code: Select all

# chmod 606 /dev/input/mice

Now, does this have any security implications?
I also have my /dev/snd set up like this:
https://github.com/stefan11111/config-f ... /mknod_snd
I still wonder though, how is the mouse any different from the keyboard in this case?

Neddy,

Can you post the output of ls -lah /dev/tty?
I fiddled with it's permissions and would like to set them back to default.

[GDH-gentoo]

The fix was:

Code: Select all

# chmod 606 /dev/input/mice

Now, does this have any security implications?

You are giving every program that runs on your computer full access to a hardware device, so they can do whatever they want with it. Many people might argue that you are making your attack surface larger...

[stefan11111]

The fix was:

Code: Select all

# chmod 606 /dev/input/mice

Now, does this have any security implications?

You are giving every program that runs on your computer full access to a hardware device, so they can do whatever they want with it. Many people might argue that you are making your attack surface larger...

Another solution is:

Code: Select all

# chown stefan:root /dev/input/mice

My user is called stefan.

Code: Select all

$ ls -lah /dev/input/mice
crw------- 1 stefan root 13, 63 Mar  6 10:40 /dev/input/mice

Is this any better?
Doing this doesn't work, even though my user is in the input group:

Code: Select all

# chown root:input /dev/input/mice

[NeddySeagoon]

stefan11111

Code: Select all

ls /dev/input/m* -l
crw------- 1 root root 13,  63 Nov  4  2021 /dev/input/mice

is what I have. 606 lets anyone read and write /dev/input/mice

A better solution may be to make it crw-rw---- 1 root video.
You will be in the video group anyway, for accelerated graphics. If you wanted finer grain control of access to hardware devices you could create a new group, or several if that helped.

Code: Select all

$ ls /dev/tty -l
crw-rw-rw- 1 root root 5, 0 Mar 19 19:34 /dev/tty

-- edit --
From that Mar 19 date, its not what was originally there. Something remade it at that time.