4 ms·

When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.

wmf 8mo ago
Around 20 years after suid is deprecated.
NekkoDroid 8mo ago
Probably never for package based distros. I could see it happening for image based distros, where systemd is slowly but surely providing all the building blocks for. It has had the option for `NoNewPrivileges=` in the `system.conf` since v239, so it isn't exactly difficult to disable for the entire system. Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, groupmems, ...), though alot can also work without being suid just more resticted in what they can do.
- yjftsjthsd-h 8mo ago
  > how many binaries are suid binaries while they probably shouldn't be (passwd I would expect an unprivileged user to be able to change their own password. How else would that work?
  - kam 8mo ago
    Send a message to a socket-activated daemon running as a UID with write access to the password database.
    - linsomniac 8mo ago
      Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.
    - deleted 8mo ago
      [deleted]
  - magicalhippo 8mo ago
    > How else would that work? Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.
  - NekkoDroid 8mo ago
    systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).
- Vogtinator 8mo ago
  With https://github.com/thkukuk/account-utils https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.
simoncion 8mo ago
> When will these distros accept suid was a mistake and disable it. I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode. 1) Do you believe that this program is unsafe when compiled and set suid root? 2) How do you propose that I replace it with something that isn't suid root? #include <string.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> void maybe_do(const char * cmd) { if(system(cmd)) { perror(cmd); exit(2); } } int main(int argc, char** argv) { if(argc != 2) { return 1; } int turnOff = strncmp("on", argv[1], 2); if(setuid(0)) { perror("uid"); return 2; } if(turnOff) { maybe_do("/usr/bin/cpupower frequency-set --governor schedutil > /dev/null"); maybe_do("/bin/echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level"); } else { maybe_do("/usr/bin/cpupower frequency-set --governor performance > /dev/null"); maybe_do("/bin/echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"); } return 0; }
- c-hendricks 8mo ago
  Run the part that needs root as a daemon, some server that accepts http requests Use sudo and allow anyone to run the binary without password auth Use the existing gamemode package Those are a few options, of course it's your system in the end
  - simoncion 8mo ago
    First off, thanks very much for giving me exactly what I asked for. You propose that instead of sometimes running ~five lines of C as root, I do one of the following: 1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in. 2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs. 3) Use a package that has several-thousand lines of C (and who knows how many lines of Python) running as root and does way more than I need. All of these alternatives tell a story: The alternative to running ~five lines of C as root is to run *many* more lines as root. This is kinda my point. Some people rave about setuid programs and assert that they should not exist, but when you absolutely need to let an unprivileged user do things that only root is ordinarily permitted to do you're going to have to have code running as root. And when you have code running as root, you have to be careful to get it right. Whether it's running from a setuid root-owned executable, a persistent daemon running as root, or a regular program that sudo [1] has executed as root is irrelevant: it's all code running as root! [0] People shit on sudo for both being setuid root and for being "too complicated". I love the hell out of the program; it's an essential part of how I get shit done on my PC. sudo is -very seriously- a great tool. [1] ...or similar...

wmf 8mo ago

Around 20 years after suid is deprecated.

NekkoDroid 8mo ago

Probably never for package based distros. I could see it happening for image based distros, where systemd is slowly but surely providing all the building blocks for. It has had the option for `NoNewPrivileges=` in the `system.conf` since v239, so it isn't exactly difficult to disable for the entire system. Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, groupmems, ...), though alot can also work without being suid just more resticted in what they can do.

yjftsjthsd-h 8mo ago
> how many binaries are suid binaries while they probably shouldn't be (passwd I would expect an unprivileged user to be able to change their own password. How else would that work?
- kam 8mo ago
  Send a message to a socket-activated daemon running as a UID with write access to the password database.
  - linsomniac 8mo ago
    Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.
  - deleted 8mo ago
    [deleted]
- magicalhippo 8mo ago
  > How else would that work? Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.
- NekkoDroid 8mo ago
  systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).
Vogtinator 8mo ago
With https://github.com/thkukuk/account-utils https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.

simoncion 8mo ago

> When will these distros accept suid was a mistake and disable it. I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode. 1) Do you believe that this program is unsafe when compiled and set suid root? 2) How do you propose that I replace it with something that isn't suid root? #include <string.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> void maybe_do(const char * cmd) { if(system(cmd)) { perror(cmd); exit(2); } } int main(int argc, char** argv) { if(argc != 2) { return 1; } int turnOff = strncmp("on", argv[1], 2); if(setuid(0)) { perror("uid"); return 2; } if(turnOff) { maybe_do("/usr/bin/cpupower frequency-set --governor schedutil > /dev/null"); maybe_do("/bin/echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level"); } else { maybe_do("/usr/bin/cpupower frequency-set --governor performance > /dev/null"); maybe_do("/bin/echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"); } return 0; }

c-hendricks 8mo ago
Run the part that needs root as a daemon, some server that accepts http requests Use sudo and allow anyone to run the binary without password auth Use the existing gamemode package Those are a few options, of course it's your system in the end
- simoncion 8mo ago
  First off, thanks very much for giving me exactly what I asked for. You propose that instead of sometimes running ~five lines of C as root, I do one of the following: 1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in. 2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs. 3) Use a package that has several-thousand lines of C (and who knows how many lines of Python) running as root and does way more than I need. All of these alternatives tell a story: The alternative to running ~five lines of C as root is to run *many* more lines as root. This is kinda my point. Some people rave about setuid programs and assert that they should not exist, but when you absolutely need to let an unprivileged user do things that only root is ordinarily permitted to do you're going to have to have code running as root. And when you have code running as root, you have to be careful to get it right. Whether it's running from a setuid root-owned executable, a persistent daemon running as root, or a regular program that sudo [1] has executed as root is irrelevant: it's all code running as root! [0] People shit on sudo for both being setuid root and for being "too complicated". I love the hell out of the program; it's an essential part of how I get shit done on my PC. sudo is -very seriously- a great tool. [1] ...or similar...