4 ms·

If you could configure your linux kernel without suid support, that would be huge benefit for security, IMO. suid feature is huge security hole. Whether fighti

If you could configure your linux kernel without suid support, that would be huge benefit for security, IMO. suid feature is huge security hole. Whether fighting one particular suid binary worth it, is questionable indeed. But this is good direction. Another modern approach to this problem is run0 from systemd.

westurner 2y ago
"List of Unix binaries that can be used to bypass local security restrictions" (2023) https://news.ycombinator.com/item?id=36637980 https://news.ycombinator.com/item?id=36637980 "Fedora 40 Plans To Unify /usr/bin and /usr/sbin" (2024) https://news.ycombinator.com/item?id=38757975 https://news.ycombinator.com/item?id=38757975 ; a find expression to locate files with the setuid and setgid bits, setcap, man run0: https://www.freedesktop.org/software/systemd/man/devel/run0.html https://www.freedesktop.org/software/systemd/man/devel/run0....
arp242 2y ago
> IMO. suid feature is huge security hole. As opposed to running background processes as root...? This is just mindless dogma at this point. You're going to need something to elevate permissions, and setuid is as good of a scheme as any. ssh or run0 are not magic and just as "vulnerable" as setuid or anything else. Any of these schemes are "security holes" if you abuse it.
- herczegzsolt 2y ago
  The argument is, that in case of sudo, the caller (potential attacker) controls the environment. In many cases, software or libraries are not made with a hostile environment in mind. Think of LD_PRELOAD or PATH ... When there's a daemon running in the background, the attack surface is more commonly understood. The environment is not under attacker control. Libraries rarely treat data from socket as "trusted" but often blindly trust environment variables, or stdin/stdout/stderr.
  - arp242 2y ago
    That has nothing to do with setuid, and is a very different argument from an unqualified "suid feature is huge security hole." sudo etc. already clear much of the environment. And you're going to want to keep some of it because people expect "sudo foo" to work (which you can't do without PATH).

westurner 2y ago

"List of Unix binaries that can be used to bypass local security restrictions" (2023) https://news.ycombinator.com/item?id=36637980 https://news.ycombinator.com/item?id=36637980 "Fedora 40 Plans To Unify /usr/bin and /usr/sbin" (2024) https://news.ycombinator.com/item?id=38757975 https://news.ycombinator.com/item?id=38757975 ; a find expression to locate files with the setuid and setgid bits, setcap, man run0: https://www.freedesktop.org/software/systemd/man/devel/run0.html https://www.freedesktop.org/software/systemd/man/devel/run0....

arp242 2y ago

> IMO. suid feature is huge security hole. As opposed to running background processes as root...? This is just mindless dogma at this point. You're going to need something to elevate permissions, and setuid is as good of a scheme as any. ssh or run0 are not magic and just as "vulnerable" as setuid or anything else. Any of these schemes are "security holes" if you abuse it.

herczegzsolt 2y ago
The argument is, that in case of sudo, the caller (potential attacker) controls the environment. In many cases, software or libraries are not made with a hostile environment in mind. Think of LD_PRELOAD or PATH ... When there's a daemon running in the background, the attack surface is more commonly understood. The environment is not under attacker control. Libraries rarely treat data from socket as "trusted" but often blindly trust environment variables, or stdin/stdout/stderr.
- arp242 2y ago
  That has nothing to do with setuid, and is a very different argument from an unqualified "suid feature is huge security hole." sudo etc. already clear much of the environment. And you're going to want to keep some of it because people expect "sudo foo" to work (which you can't do without PATH).