6 ms·

It seems straightforward to just enumerate every setuid program that ships on the vast majority of distros and check for this issue and patch what's there. That

It seems straightforward to just enumerate every setuid program that ships on the vast majority of distros and check for this issue and patch what's there. That seems like the simplest approach with no concern for breaking anything. Also, a sysctl for rejecting the call would seem reasonable.

hedora 5y ago
Agreed. Also, the existence of this bug makes me wonder if I can simply delete polkit. What other rookie mistakes lie within? I learned how to parse argv properly in CS 50 (so, before CS 101).
- rwmj 5y ago
  pkexec was a kludge to replace consolehelper and both were actually supposed to have been removed in 2013(!) but the transition didn't happen fully. In fact some are still using consolehelper. For the whole sorry tale, https://lwn.net/Articles/883547/ https://lwn.net/Articles/883547/ https://lwn.net/SubscriberLink/883547/f9a8f4e4be157f91/ https://lwn.net/SubscriberLink/883547/f9a8f4e4be157f91/
  - fulafel 5y ago
    Interesting. Ironically the reason pkexec exists on Ubuntu server installs seems to be that they want to have a package management service (PackageKit) hanging off dbus even in headless setups, for reasons that aren't obvious. There have been earlier local root bugs caused by PackageKit as well[1]. (The irony being, the LWN documented discussion where a dev defends ipc-accessible privileged daemons as more secure and justifies pkexec as facilitating access to these). [1] https://ubuntu.com/security/notices/USN-4538-1 https://ubuntu.com/security/notices/USN-4538-1
    - simcop2387 5y ago
      I believe it gets used for the unattended-upgrades system to manage security updates. Not sure if that's the best way to do it but I believe it's using packagekit to do the actual work.
      - fulafel 5y ago
        That was my guess also at first but seems this is not the case, it just runs as root and calls apt directly. There's no dependency to packagekit, and it only uses dbus in the unattended-upgrade-shutdown script for some shutdown event monitoring business from systemd.
- WesolyKubeczek 5y ago
  The whole discussion of alternatives is, alas, akin to passing a hot potato around. I, for one, don't quite see how keeping a daemon whose only job is to execute arbitrary privileged commands any safer. You can have a hole where it parses the request. You can have a hole where it checks whether the requesting party is indeed authorized to make such requests. You can have a hole at the point of it invoking execve(). Indeed, you can put in the same hole pkexec used to have! You still need to exercise due diligence to write that daemon as tightly as can be so all those places don't pose a risk. But with having a resident daemon approach you lose the process ownership, which sometimes is damn handy to have. Accidentally granting root to do a wrong thing and then not even being able to kill the thing with Ctrl-C or xkill is quite disempowering.
  - hedora 5y ago
    I still haven't gotten over the transition from init to systemd. One reason is that I'm unconvinced it makes sense to have a daemon that passes out root privileges after boot. I'm a fan of "keep it simple," and UNIX/Linux/BSD survived for decades without such a daemon.
    - mst 5y ago
      I understand entirely on a philosphical level but while debugging systemd regularly makes me angry it's still less often than other people's SysV init scripts used to do so, so I've made my peace with why people were happy making the switch. Naturally I'd personally prefer rc.subr or s6 or nosh (though I've seen people footgun themselves with all of those too, albeit less often than SysV) but it is what it is, and most days I can bring myself to believe that the systemd transition was the sort of imperfect net win that's usually as good as you get in an ecosystem as complex as this one.
- captainmuon 5y ago
  Polkit (I think it is polkit) is so annoying. When I forget to use sudo, it asks me in a nonstandard prompt for a password. But I don't have a password on some machines, I logged in via ssh key and have passwordless sudo. At the same time, you can still not elevate inside an application. I would love to run a command to open a single file as root in vim, or VS code, or copy one file as root in Nautilus. I think you can click a little lock in Gnome settings somewhere and unlock certain pages, but it is far from widespread.
gnulinux 5y ago
What are some setuid program in popular distros? The only ones I'm aware of are `sudo` and `su`? Do programs such as `systemd` require setuid?
- soneil 5y ago
  I count 20 on mine. Surprisingly, none of them are systemd. (find / -perm 4000)
  - bonzini 5y ago
    systemd developers generally prefer having a privileged daemon, and an unprivileged program doing RPC with the other. See for example systemd/systemctl, timesyncd/timesyncctl, etc.
  - Arnavion 5y ago
    `find / -perm /4000` to be precise. It's unlikely you have any suid binaries with exactly 4000 mode.
- josephcsible 5y ago
  There's a bunch, e.g., mount, umount, fusermount, crontab, passwd, and chsh.
captainmuon 5y ago
It seems a bit extreme to add a syscall for this. As you said, they have to bite the bullet and fix the suid programs. And why not just fix the exec call in userland? I'm not sure who supplies it - the C standard library or the kernel headers. You would fix all the cases of accidentally calling something with argc==0 and it would not run afoul of the kernel breaking userspace.
- saagarjha 5y ago
  sysctl ≠ syscall, FWIW
  - deleted 5y ago
    [deleted]
  - captainmuon 5y ago
    Ah OK, that makes more sense. TIL!

hedora 5y ago

Agreed. Also, the existence of this bug makes me wonder if I can simply delete polkit. What other rookie mistakes lie within? I learned how to parse argv properly in CS 50 (so, before CS 101).

rwmj 5y ago
pkexec was a kludge to replace consolehelper and both were actually supposed to have been removed in 2013(!) but the transition didn't happen fully. In fact some are still using consolehelper. For the whole sorry tale, https://lwn.net/Articles/883547/ https://lwn.net/Articles/883547/ https://lwn.net/SubscriberLink/883547/f9a8f4e4be157f91/ https://lwn.net/SubscriberLink/883547/f9a8f4e4be157f91/
- fulafel 5y ago
  Interesting. Ironically the reason pkexec exists on Ubuntu server installs seems to be that they want to have a package management service (PackageKit) hanging off dbus even in headless setups, for reasons that aren't obvious. There have been earlier local root bugs caused by PackageKit as well[1]. (The irony being, the LWN documented discussion where a dev defends ipc-accessible privileged daemons as more secure and justifies pkexec as facilitating access to these). [1] https://ubuntu.com/security/notices/USN-4538-1 https://ubuntu.com/security/notices/USN-4538-1
  - simcop2387 5y ago
    I believe it gets used for the unattended-upgrades system to manage security updates. Not sure if that's the best way to do it but I believe it's using packagekit to do the actual work.
    - fulafel 5y ago
      That was my guess also at first but seems this is not the case, it just runs as root and calls apt directly. There's no dependency to packagekit, and it only uses dbus in the unattended-upgrade-shutdown script for some shutdown event monitoring business from systemd.
WesolyKubeczek 5y ago
The whole discussion of alternatives is, alas, akin to passing a hot potato around. I, for one, don't quite see how keeping a daemon whose only job is to execute arbitrary privileged commands any safer. You can have a hole where it parses the request. You can have a hole where it checks whether the requesting party is indeed authorized to make such requests. You can have a hole at the point of it invoking execve(). Indeed, you can put in the same hole pkexec used to have! You still need to exercise due diligence to write that daemon as tightly as can be so all those places don't pose a risk. But with having a resident daemon approach you lose the process ownership, which sometimes is damn handy to have. Accidentally granting root to do a wrong thing and then not even being able to kill the thing with Ctrl-C or xkill is quite disempowering.
- hedora 5y ago
  I still haven't gotten over the transition from init to systemd. One reason is that I'm unconvinced it makes sense to have a daemon that passes out root privileges after boot. I'm a fan of "keep it simple," and UNIX/Linux/BSD survived for decades without such a daemon.
  - mst 5y ago
    I understand entirely on a philosphical level but while debugging systemd regularly makes me angry it's still less often than other people's SysV init scripts used to do so, so I've made my peace with why people were happy making the switch. Naturally I'd personally prefer rc.subr or s6 or nosh (though I've seen people footgun themselves with all of those too, albeit less often than SysV) but it is what it is, and most days I can bring myself to believe that the systemd transition was the sort of imperfect net win that's usually as good as you get in an ecosystem as complex as this one.
captainmuon 5y ago
Polkit (I think it is polkit) is so annoying. When I forget to use sudo, it asks me in a nonstandard prompt for a password. But I don't have a password on some machines, I logged in via ssh key and have passwordless sudo. At the same time, you can still not elevate inside an application. I would love to run a command to open a single file as root in vim, or VS code, or copy one file as root in Nautilus. I think you can click a little lock in Gnome settings somewhere and unlock certain pages, but it is far from widespread.

gnulinux 5y ago

What are some setuid program in popular distros? The only ones I'm aware of are `sudo` and `su`? Do programs such as `systemd` require setuid?

soneil 5y ago
I count 20 on mine. Surprisingly, none of them are systemd. (find / -perm 4000)
- bonzini 5y ago
  systemd developers generally prefer having a privileged daemon, and an unprivileged program doing RPC with the other. See for example systemd/systemctl, timesyncd/timesyncctl, etc.
- Arnavion 5y ago
  `find / -perm /4000` to be precise. It's unlikely you have any suid binaries with exactly 4000 mode.
josephcsible 5y ago
There's a bunch, e.g., mount, umount, fusermount, crontab, passwd, and chsh.

captainmuon 5y ago

It seems a bit extreme to add a syscall for this. As you said, they have to bite the bullet and fix the suid programs. And why not just fix the exec call in userland? I'm not sure who supplies it - the C standard library or the kernel headers. You would fix all the cases of accidentally calling something with argc==0 and it would not run afoul of the kernel breaking userspace.

saagarjha 5y ago
sysctl ≠ syscall, FWIW
- deleted 5y ago
  [deleted]
- captainmuon 5y ago
  Ah OK, that makes more sense. TIL!