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.
With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.
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.
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).
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.
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
Yup! There's no way around that if in the end you need elevated privileges somewhere.
What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d
...huh. There isn't. I checked out the git repo, and read the contents of the daemon directory. I guess I looked at the meson stuff at top level and thought to myself "Meson? Isn't that one of the half-billion Python build systems?" [0] and -from that thought- assumed that there was some Python in the directories I didn't examine. (It turns out that there is not. It's all C and configuration.)
What the other options allow is to contain the blast radius.
I can do that by removing the "other" executable bit, adding the group executable bit, and setting the file's group appropriately to control access. You are limited to a single group, but it's not like you're unable to "contain the blast radius".
With the daemon you can control access via groups on the socket...
As long as it's a UNIX socket, yes. (Getting guaranteed information about the identity of the process on the other side of such a socket is one of my favorite things about them.)
Yup! There's no way around that if in the end you need elevated privileges somewhere.
Exactly. I hope the "setuid is evil and shouldn't exist" people who are complaining in good faith are capable of both realizing this and also recognizing that "just daemonize it" and "just run it with sudo" are -at times- not obviously the right thing to do.
I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.
As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"
[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.
Building services should be easy. The fact that Linux does not have an easy to use IPC mechanism is the fault of Linux. Yes, systemd can make it so services don't have to run until they are connected, and yes dbus exists, but it's overcomplicated for something which should be easy to make. This is a Linux devex failure.
2)
I agree this is going in the wrong direction. Full sudo is also even more in the wrong direction away from only giving the minimal amount of privileges to the code that needs it.
3)
See my response to 1). Making programs with different capabilities able to talk to each other should be made dead easy to do.
The fact that Linux does not have an easy to use IPC mechanism...
What? Send bytes down a UNIX socket. There's nothing easier, really. It's so simple, it's what systemd uses to have monitored daemons indicate that they're now actually running.
The rest of your commentary has nothing to do with my commentary about unprivved users running code as root. Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
It really isn't. You have to a whole protocol on top of it if you want to use it and then build out the daemon logic yourself. If it was so easy why didn't you write it instead of making a suid binary. The complexity is not sufficiently abstracted away.
Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
My whole response was addressing the core of your argument in your post "The alternative to running ~five lines of C as root is to run many more lines as root." The reason it's many more lines is because the Linux developers did not write abstractions to make it simple to do. If you read my original post in this comment chain you will see that I do have problems with setuid executables and want distros to disable them.
1) Run a persistent whole-ass daemon using something for IPC
This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.
Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;)
[0] Seriously, it's fucking complicated. Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after a week when I couldn't even get the Impersonation equivalent of "Hello world" to work.
In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed
Comments
When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
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.
With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.
I would expect an unprivileged user to be able to change their own password. How else would that work?
Send a message to a socket-activated daemon running as a UID with write access to the password database.
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.
Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.
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).
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?
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
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:
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...
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
Yup! There's no way around that if in the end you need elevated privileges somewhere.
What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d
There's no python in gamemode...
...huh. There isn't. I checked out the git repo, and read the contents of the daemon directory. I guess I looked at the meson stuff at top level and thought to myself "Meson? Isn't that one of the half-billion Python build systems?" [0] and -from that thought- assumed that there was some Python in the directories I didn't examine. (It turns out that there is not. It's all C and configuration.)
I can do that by removing the "other" executable bit, adding the group executable bit, and setting the file's group appropriately to control access. You are limited to a single group, but it's not like you're unable to "contain the blast radius".
As long as it's a UNIX socket, yes. (Getting guaranteed information about the identity of the process on the other side of such a socket is one of my favorite things about them.)
Exactly. I hope the "setuid is evil and shouldn't exist" people who are complaining in good faith are capable of both realizing this and also recognizing that "just daemonize it" and "just run it with sudo" are -at times- not obviously the right thing to do.
[0] It's not!
I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.
As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"
[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.
Building services should be easy. The fact that Linux does not have an easy to use IPC mechanism is the fault of Linux. Yes, systemd can make it so services don't have to run until they are connected, and yes dbus exists, but it's overcomplicated for something which should be easy to make. This is a Linux devex failure.
I agree this is going in the wrong direction. Full sudo is also even more in the wrong direction away from only giving the minimal amount of privileges to the code that needs it.
See my response to 1). Making programs with different capabilities able to talk to each other should be made dead easy to do.
What? Send bytes down a UNIX socket. There's nothing easier, really. It's so simple, it's what systemd uses to have monitored daemons indicate that they're now actually running.
The rest of your commentary has nothing to do with my commentary about unprivved users running code as root. Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
It really isn't. You have to a whole protocol on top of it if you want to use it and then build out the daemon logic yourself. If it was so easy why didn't you write it instead of making a suid binary. The complexity is not sufficiently abstracted away.
My whole response was addressing the core of your argument in your post "The alternative to running ~five lines of C as root is to run many more lines as root." The reason it's many more lines is because the Linux developers did not write abstractions to make it simple to do. If you read my original post in this comment chain you will see that I do have problems with setuid executables and want distros to disable them.
This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.
Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;)
[0] Seriously, it's fucking complicated. Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after a week when I couldn't even get the Impersonation equivalent of "Hello world" to work.
In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed
1) I believe the current iteration you have of it is safe.
2) I suggest that a service is created for managing system performance that exposes an API to your user to turn on and off game mode.
My commentary here [0] directly relates to your #2.
[0] <https://news.ycombinator.com/item?id=47436085>
Around 20 years after suid is deprecated.