| View previous topic :: View next topic |
| Author |
Message |
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
 Posted: Sat Mar 25, 2023 9:41 am Post subject: non-root xorg static /dev |
 |
|
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.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
 |
Leonardo.b
Guru
Joined: 10 Oct 2020
Posts: 308
|
| Posted: Sat Mar 25, 2023 10:12 am Post subject: |
|
|
Look into Xorg logs, something alike "permission denied".
Probably you have to adjust some permissions in /dev to access input devices. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54644
Location: 56N 3W
|
| Posted: Sat Mar 25, 2023 10:33 am Post subject: |
|
|
stefan11111,
| Quote: | | 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.
| Tony Hoare wrote: | | 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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
| Posted: Sat Mar 25, 2023 10:52 am Post subject: |
|
|
| NeddySeagoon wrote: | stefan11111,
| Quote: | | 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.
| NeddySeagoon wrote: |
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.
| NeddySeagoon wrote: |
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.
| Tony Hoare wrote: | | 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?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54644
Location: 56N 3W
|
| Posted: Sat Mar 25, 2023 11:41 am Post subject: |
|
|
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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Leonardo.b
Guru
Joined: 10 Oct 2020
Posts: 308
|
| Posted: Sat Mar 25, 2023 1:20 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54644
Location: 56N 3W
|
| Posted: Sat Mar 25, 2023 1:41 pm Post subject: |
|
|
Leonardo.b,
Your favourite search engine will show you how.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6179
Location: Dallas area
|
| Posted: Sat Mar 25, 2023 1:49 pm Post subject: |
|
|
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: | 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.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1777
Location: South America
|
| Posted: Sat Mar 25, 2023 2:05 pm Post subject: |
|
|
| stefan11111 wrote: | | 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.
| Anon-E-moose wrote: | | 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.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
Last edited by GDH-gentoo on Sat Mar 25, 2023 3:07 pm; edited 3 times in total |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
| Posted: Sat Mar 25, 2023 2:29 pm Post subject: |
|
|
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.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1777
Location: South America
|
| Posted: Sat Mar 25, 2023 2:50 pm Post subject: |
|
|
| stefan11111 wrote: | | 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.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
Leonardo.b
Guru
Joined: 10 Oct 2020
Posts: 308
|
| Posted: Sat Mar 25, 2023 2:57 pm Post subject: |
|
|
| NeddySeagoon wrote: | 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. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
| Posted: Sat Mar 25, 2023 3:08 pm Post subject: |
|
|
| GDH-gentoo wrote: |
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.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1777
Location: South America
|
| Posted: Sat Mar 25, 2023 3:43 pm Post subject: |
|
|
OK, then post Xorg's log. Any insufficient permissions issues should show up there.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54644
Location: 56N 3W
|
| Posted: Sat Mar 25, 2023 4:23 pm Post subject: |
|
|
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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
|
| Back to top |
|
|
Leonardo.b
Guru
Joined: 10 Oct 2020
Posts: 308
|
| Posted: Sat Mar 25, 2023 5:39 pm Post subject: |
|
|
| NeddySeagoon, I understand, that makes sense. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1777
Location: South America
|
| Posted: Sat Mar 25, 2023 6:33 pm Post subject: |
|
|
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 wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54644
Location: 56N 3W
|
| Posted: Sat Mar 25, 2023 6:52 pm Post subject: |
|
|
stefan11111,
It that log with Xorg suid or not?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
| Posted: Sat Mar 25, 2023 7:13 pm Post subject: |
|
|
| NeddySeagoon wrote: | 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/blob/main/Xorg.0.log.new
Yes, /dev/input/mice does exist.
| Code: | $ ls -lah /dev/input/mice
crw------- 1 root root 13, 63 Mar 6 10:40 /dev/input/mice
|
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1777
Location: South America
|
| Posted: Sat Mar 25, 2023 7:17 pm Post subject: |
|
|
| Code: | [ 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.
| stefan11111 wrote: | | Code: | $ 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.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
| Posted: Sat Mar 25, 2023 7:37 pm Post subject: |
|
|
| GDH-gentoo wrote: | | Code: | [ 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.
| stefan11111 wrote: | | Code: | $ 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: | | # 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-files/blob/main/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.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1777
Location: South America
|
| Posted: Sat Mar 25, 2023 7:45 pm Post subject: |
|
|
| stefan11111 wrote: | The fix was:
| Code: | | # 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...
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 937
Location: Romania
|
| Posted: Sat Mar 25, 2023 7:59 pm Post subject: |
|
|
| GDH-gentoo wrote: | | stefan11111 wrote: | The fix was:
| Code: | | # 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: | # chown stefan:root /dev/input/mice
|
My user is called stefan.
| Code: | $ 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: | | # chown root:input /dev/input/mice |
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54644
Location: 56N 3W
|
| Posted: Sat Mar 25, 2023 8:13 pm Post subject: |
|
|
stefan11111
| Code: | 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: | $ 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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
Unsupported Software
