| View previous topic :: View next topic |
| Author |
Message |
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 949
Location: Romania
|
 Posted: Sat Mar 25, 2023 8:40 pm Post subject: |
 |
|
| NeddySeagoon wrote: | 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. |
I did chown root:input /dev/input/mice and chmod 660 /dev/input/mice and everything worked.
I am both in the video group and in the input group.
I also applied these things to that /dev/snd script to make it more secure. You can see the updated version here:
https://github.com/stefan11111/config-files/blob/main/mknod_snd
Is doing things this way more/less secure than the suid way?
_________________
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: 54744
Location: 56N 3W
|
| Posted: Sat Mar 25, 2023 8:45 pm Post subject: |
|
|
stefan11111,
You have security against threats, without knowing the treats you want to guard against, the question cannot be answered.
_________________
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: 949
Location: Romania
|
| Posted: Sat Mar 25, 2023 8:57 pm Post subject: |
|
|
| NeddySeagoon wrote: | stefan11111,
You have security against threats, without knowing the treats you want to guard against, the question cannot be answered. |
The treat I want to guard against is programs being exploited and taking advantage of this.
I'm mostly concerned about librewolf, since it's a browser and a huge target for bad actors.
_________________
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: 1791
Location: South America
|
| Posted: Sat Mar 25, 2023 9:07 pm Post subject: |
|
|
| stefan11111 wrote: | I am both in the video group and in the input group.
[...]
Is doing things this way more/less secure than the suid way? |
You are giving every program that runs on your computer with your user as its effective user full access to several hardware devices, so they can do whatever they want with them. Many people might argue that you are making your attack surface larger...
Keyloggers will probably love that your user is a member of the input and tty groups...
_________________
| 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: 949
Location: Romania
|
| Posted: Sat Mar 25, 2023 9:21 pm Post subject: |
|
|
| GDH-gentoo wrote: | | stefan11111 wrote: | I am both in the video group and in the input group.
[...]
Is doing things this way more/less secure than the suid way? |
You are giving every program that runs on your computer with your user as its effective user full access to several hardware devices, so they can do whatever they want with them. Many people might argue that you are making your attack surface larger...
Keyloggers will probably love that your user is a member of the input and tty groups... |
Just ran chown root:video /dev/input/mice and removed my user from the input group.
If I remove my user from the tty group, I can't start xorg at all.
| Code: | $ groups stefan
tty audio video stefan
|
What groups are you in?
EDIT
Seems like chown root:video /dev/tty0 and chown root:video /dev/tty7 allow me to start xorg without being in the tty group, but it likely makes little difference.
When I log in, /dev/tty1 gets owner stefan:tty. Shouldn't this be used when I start xorg with --vt1?
I also seems like starting xorg with startx --vt1 does nothing.
_________________
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: 1791
Location: South America
|
| Posted: Sat Mar 25, 2023 10:13 pm Post subject: |
|
|
| stefan11111 wrote: | | What groups are you in? |
I only made my unprivileged user a member of wheel and portage. No groups associated with hardware devices. But I use either SDDM —which spawns an Xorg child that runs as root—, or startx and elogind. And also use systemd-udevd, so I have libudev and thus can use xf86-input-evdev as the input driver.
If I had no elogind and a static /dev, though, I would just go with a suid Xorg, like NeddySeagoon.
_________________
| 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: 949
Location: Romania
|
| Posted: Sat Mar 25, 2023 11:12 pm Post subject: |
|
|
Looks like I was just using startx wrong.
Its
not
I have this in my .bashrc to automatically set this on any tty:
| Code: | | alias startx="startx -- vt$(tty | sed -e 's|/dev/tty||')" |
Using this allows me to not have my user in the tty group, while having all the /dev/tty* belong to root:tty, except the one I'm logged into, which belongs to stefan:tty.
From what I can see, It's either have /dev/input/mice belong to a group that I'm a part of, or I set the suid bit on xorg.
But is this any more dangerous than what I'm using for /dev/snd?
And why does the keyboard work without any of this, while the mouse doesn't?
And how can any of these be practically exploited?
For some reason, the wiki and a news item all advise against suid.
If SDDM spawns your xorg as root, don't you get a lot of gui apps screaming at you because you launch them as root?
_________________
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: 1791
Location: South America
|
| Posted: Sun Mar 26, 2023 1:28 am Post subject: |
|
|
| stefan11111 wrote: | | And why does the keyboard work without any of this, while the mouse doesn't? |
Different special files involved. xf86-input-keyboard uses the /dev/ttyn file that Xorg already opened. xf86-input-mouse needs to open the special file named in the Device option of the corresponding InputDevice section in xorg.conf. /dev/input/mice in this case. Both require privileges in general, except the /dev/ttyn file in the special case in which you tell Xorg to open the one that is owned by you.
| stefan11111 wrote: | | For some reason, the wiki and a news item all advise against suid. |
Already addressed in previous posts of this thread.
| stefan11111 wrote: | | If SDDM spawns your xorg as root, don't you get a lot of gui apps screaming at you because you launch them as root? |
Xorg runs as root, not the GUI applications. Those run as separate processes, have the effective user ID of the (unprivileged) user that logged in with SDDM, and don't interact with hardware devices. They are X clients, they communicate with the X server, which does that on their behalf.
_________________
| 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: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 8:40 am Post subject: |
|
|
Yet another way of getting this to work is:
| Code: |
# groupadd xorg
# chmod 2711 /usr/bin/Xorg
# chown root:xorg /usr/bin/Xorg
# chown root:xorg /dev/input/mice |
From my understanding, this only gives Xorg permissions over the files owned by group xorg, which in this case is only /dev/input/mice and no longer gives my user permission over that file.
It this better than both solutions?
This no longer gives acces to /dev/input/mice to the programs I start.
This doesn't give Xorg full root privileges.
_________________
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: 54744
Location: 56N 3W
|
| Posted: Sun Mar 26, 2023 9:29 am Post subject: |
|
|
stefan11111,
It all comes back to the threat you trying to defend against.
If the threat can't happen to you there is nothing to defend against as the problem cannot be turned into an attack.
In your own case ... what is the problem with running xorg suid?
Here, I'm the only user. That makes many potential vulnerabilities irrelevant.
_________________
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: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 9:40 am Post subject: |
|
|
| NeddySeagoon wrote: | stefan11111,
It all comes back to the threat you trying to defend against.
If the threat can't happen to you there is nothing to defend against as the problem cannot be turned into an attack.
In your own case ... what is the problem with running xorg suid?
Here, I'm the only user. That makes many potential vulnerabilities irrelevant. |
Say I visit a malicious website, which exploits a vulnerability in librewolf.
If that vulnerability also allows an attacker to get access to my X session, I would like the damage to be contained and to not give an attacker root access.
I am mostly concerned about something like this
There is also the principle of least privilege.
_________________
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
|
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 12:41 pm Post subject: |
|
|
Seems like this exploit doesn't work even with suid xorg, mush less with mine.
I also wrote my own su and I can toggle empty password support at build time.
https://github.com/stefan11111/su
| Leonardo.b wrote: |
I like setgid solution.
Beware upgrades will change /usr/bin/Xorg permissions back to default.
|
It seems like it is the time to learn ebuilds, or just set permissions after every update.
_________________
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 |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3477
|
|
| Back to top |
|
|
Jimmy Jazz
Guru
Joined: 04 Oct 2004
Posts: 333
Location: Strasbourg
|
| Posted: Sun Mar 26, 2023 2:27 pm Post subject: |
|
|
what about sys-auth/seatd instead elogind ? There is an ebuild for it.
Also setpriv and the right capabilities could help too. I was unable to make it work with lightdm (X runs but the display stays black) 
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
| Code: |
+----+----+----+
| |::::| |
| |::::| |
+----+----+----+ |
motto: WeLCRO
WritE Less Code, Repeat Often |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1791
Location: South America
|
| Posted: Sun Mar 26, 2023 2:43 pm Post subject: |
|
|
| NeddySeagoon wrote: | | In your own case ... what is the problem with running xorg suid? |
| Leonardo.b wrote: | | Running X with high privileges seems unnecessary to me, as long as the fix is cheap I don't see why using suid. |
Worth repeating: in my opinion, the killer argument against worrying too much about Xorg's privileges are display managers. For instance, every KDE user here is very likely running SDDM, so if they are in X11 mode, they are already running Xorg as root, perhaps not even noticing, whatever the permissions of the Xorg binary are.
_________________
| 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: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 2:58 pm Post subject: |
|
|
| GDH-gentoo wrote: | | NeddySeagoon wrote: | | In your own case ... what is the problem with running xorg suid? |
| Leonardo.b wrote: | | Running X with high privileges seems unnecessary to me, as long as the fix is cheap I don't see why using suid. |
Worth repeating: in my opinion, the killer argument against worrying too much about Xorg's privileges are display managers. For instance, every KDE user here is very likely running SDDM, so if they are in X11 mode, they are already running Xorg as root, perhaps not even noticing, whatever the permissions of the Xorg binary are. |
Perhaps, but I am running xorg with startx, so it very much does matter to me.
I suspect that a lot of people also start xorg like this too.
_________________
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: 1791
Location: South America
|
| Posted: Sun Mar 26, 2023 3:00 pm Post subject: |
|
|
| Jimmy Jazz wrote: | | what about sys-auth/seatd instead elogind ? [...] I was unable to make it work with lightdm |
It all boils down to what your display manager of choice expects, not what you want to run. If it is expecting to connect to the system-wide message bus and talk to a D-Bus client that implements the org.freedesktop.login1 interface, you are stuck with elogind or seatd with the elogind backend...
_________________
| 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: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 3:02 pm Post subject: |
|
|
| Jimmy Jazz wrote: | what about sys-auth/seatd instead elogind ? There is an ebuild for it.
Also setpriv and the right capabilities could help too. I was unable to make it work with lightdm (X runs but the display stays black) |
I'd rather log into a tty as root and start X that way instead of trusting another program with this.
_________________
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 |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 3:26 pm Post subject: |
|
|
Do you all have different WM/DE's installed and use a DM to more easily manage them?
Also, aren't seatd and elongid only useful for multi-user machines, where different people would log in at the same time and share resources?
I can't imagine that the average gentoo machine has multiple human users, who each have their own WM/DE.
_________________
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 |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 3:54 pm Post subject: |
|
|
Thanks.
I created this file:
| Code: | $ cat /etc/portage/env/x11-base/xorg-server
post_pkg_postinst() {
chown root:xorg /usr/bin/Xorg
chmod 2711 /usr/bin/Xorg
} |
Permissions seem to get properly set.
On another note, can someone tell me why librewolf wants xvfb?
It seems to be related to pgo, but why?
| Code: | x11-base/xorg-server:0
(x11-base/xorg-server-21.1.7:0/21.1.7::gentoo, ebuild scheduled for merge) USE="xorg -debug -elogind -minimal (-selinux) -suid -systemd -test -udev -unwind -xcsecurity -xephyr -xnest -xvfb" ABI_X86="(64)" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(x11-base/xorg-server-21.1.7:0/21.1.7::gentoo, installed) USE="xorg xvfb -debug -elogind -minimal (-selinux) -suid -systemd -test -udev -unwind -xcsecurity -xephyr -xnest" ABI_X86="(64)" pulled in by
x11-base/xorg-server[xvfb] required by (www-client/librewolf-111.0_p3:0/111::librewolf, installed) USE="X eme-free gmp-autoupdate hardened lto openh264 pgo pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp -clang -dbus -debug -geckodriver -hwaccel -jack -libproxy -screencast (-selinux) -sndio -system-png -system-python-libs -wayland -wifi" ABI_X86="(64)" L10N="-ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fur -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -sc -sco -si -sk -sl
-son -sq -sr -sv -szl -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW" |
_________________
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 |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23026
|
| Posted: Sun Mar 26, 2023 4:12 pm Post subject: |
|
|
| How do you propose to collect the profile needed for Profile Guided Optimization of a GUI program if there is no GUI on which to run it? Xvfb is likely used so the program has somewhere to pretend to display itself while collecting the profile. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1791
Location: South America
|
| Posted: Sun Mar 26, 2023 6:42 pm Post subject: |
|
|
| stefan11111 wrote: | | Do you all have different WM/DE's installed and use a DM to more easily manage them? |
I can't speak for everybody, but the answer is likely "no". If people are running a desktop environment, X11 window manager or Wayland compositor, it is probably safe to assume that it's because they want to interact with their computer using a GUI, right? A display manager provides you with a graphical login, and controls for initiating shutdown from the graphical login, so you have the GUI experience 100% of the computer's uptime, you never actually see a text user interface other than perhaps the bootloader's.
| stefan11111 wrote: | | Also, aren't seatd and elongid only useful for multi-user machines, where different people would log in at the same time and share resources? |
[GNU/]Linux and the BSDs, like the original UNIX, are multiuser, so GUI software is written by default with support for sessions from multiple users. The fact that it might happen to run on a computer with only one real human user is just a special case. Same as having an operating system with a TCP/IP stack on a computer that happens to not be connected to a network, or with support for IPv6 on a computer that happens to be connected to only IPv4 networks.
_________________
| 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: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 7:34 pm Post subject: |
|
|
NeddySeagoon,
Can you post the output of a few more commands after running them on your system?
| Code: | ls -lah /dev/null
ls -lah /dev/ptmx
ls -lah /dev | grep snd
ls -lah /dev/sr0
ls -lah /dev/rtc0
|
_________________
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 |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 949
Location: Romania
|
| Posted: Sun Mar 26, 2023 7:43 pm Post subject: |
|
|
| GDH-gentoo wrote: | | stefan11111 wrote: | | Do you all have different WM/DE's installed and use a DM to more easily manage them? |
I can't speak for everybody, but the answer is likely "no". If people are running a desktop environment, X11 window manager or Wayland compositor, it is probably safe to assume that it's because they want to interact with their computer using a GUI, right? A display manager provides you with a graphical login, and controls for initiating shutdown from the graphical login, so you have the GUI experience 100% of the computer's uptime, you never actually see a text user interface other than perhaps the bootloader's.
|
I don't think the gentoo community is known for liking GUI's and avoiding tty's.
If all you want to do is start X on boot can't you add it to the local service and have it start Xorg, either as root or non-root?
| GDH-gentoo wrote: |
| stefan11111 wrote: | | Also, aren't seatd and elongid only useful for multi-user machines, where different people would log in at the same time and share resources? |
[GNU/]Linux and the BSDs, like the original UNIX, are multiuser, so GUI software is written by default with support for sessions from multiple users. The fact that it might happen to run on a computer with only one real human user is just a special case. Same as having an operating system with a TCP/IP stack on a computer that happens to not be connected to a network, or with support for IPv6 on a computer that happens to be connected to only IPv4 networks. |
Is it good for regular users to give yet another app control over their system when they probably don't need to?
I can't see how seatd/elogind is any better than that setgid stuff.
_________________
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 |
|
|
|
Unsupported Software
