6 ms·

I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?

datadrivenangel 3y ago
SUID has flaws, but it's not clear that there are any more convenient alternatives?
- 1oooqooq 3y ago
  you missed the memo. it's dbus. (wish i could end with /s)
- semi 3y ago
  it depends on what you're needing suid for but the first thing id evaluate is if you can just grant a specific CAPAB instead.
bayindirh 3y ago
SUID mechanism doesn’t always “elevate to root”. It’s a mechanism to “run as another user” and with SGID allows great flexibility in user permission management. You can allow all kinds of (responsible) user switch tricks for multi-admin servers and multi-user systems. Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture. Moreover, removing SUID breaks tons of mechanisms and scenarios. Security of sudo can be debated, but evolving current sudo to a better state step by step is miles better than banishing and rebuilding it and making it dependent on systemd + polkit. systemd already breaks tons of UNIX conventions and way more complicated than it should be. When you think, it sounds like “conquering” another part of user space mixed with NIH (and we know the best), and making systemd more entrenched. systemd is already a pretty large surface area to attack to begin with. XZ back door reached SSHd over libaystemd. Do we need another “integrated target” to attack in Linux?
- crabbone 3y ago
  All these ideas that tie permissions to a file completely fail when files need to be accessed either over network, or inside a container. I can see how the original authors didn't consider these cases, because they simply weren't there yet... but knowing what we know today: SUID is an awful idea.
  - bayindirh 3y ago
    Sorry for my ignorance, but what’s a scenario that you run a SUID/GUID binary from a network or a container? If you access and run, it’s SSH or similar, so it works on the system scope. If it’s a container built correctly, it has its own users and isolation already, so it shouldn’t be able to fire any binary on your “base” system, and any effect is already in the container scope. I have never had the need to SUID/GUID a non executable, and didn’t need to trigger something on the system inside a container in the last ~20 years.
    - crabbone 3y ago
      > but what’s a scenario that you run a SUID/GUID binary from a network or a container? A lot of publicly available container images require elevated permissions to simply function, not for anything extraordinary. So, the user in container needs to be a superuser. It's often even not to perform the program's main function, but because various ordinary things in Linux require elevated permissions. > container built correctly That's a spherical horse in vacuum. If you write code s.t. there aren't any errors, you don't need to do error handling, right? You don't get to choose how containers are built. You need to deal with all possibilities of how containers can be built. Network filesystem? -- /usr/shared, /usr/opt and /usr/local? That's by design... very typical for cluster management software to mount these from NAS. It's also very not typical to keep these as "only text files". Pretty sure a lot of Google's stuff installs automatically into /usr/shared. I think even Go compiler and other infra at some point was being installed there by default. Finally: the same argument as with containers. You, for some reason, are trying to fantasize the world where problems don't exist because you chose the world w/o problems. But this isn't the real world. It's a fantasy. In real world, with or without reason, programmers and other computer users will do what's possible, not what you want them to do.
lucideer 3y ago
The problem with this line of thinking is it gives automatic carte blanche to anyone pointing out problems to implement "solutions" to those problems with little interrogation of whether those solutions are actually better. SUID, like any system, is flawed. Most of those flaws are balanced trade-offs; if you're addressing one you need to be aware of the severity of any counter-problems you're inevitably introducing. Lennart is well known for criticising existing systems while simultaneously ignoring & dismissing criticism of the proposed solutions - you need to be able to weigh up both sides in a balanced way. Lennart demonstrably isn't.
- panick21_ 3y ago
  > you need to be able to weigh up both sides in a balanced way. Lennart demonstrably isn't. That's why nobody uses his software. I mean just nothing he does gets adopted. The 'run0' solution uses an already existing mechanism that is already used for a lot of things.
  - lucideer 2y ago
    > nobody uses his software Yes, you're absolutely right. Popularity is the best indicator of quality.
    - panick21_ 2y ago
      Its not the best indicator but to claim its meaningless is idiotic. Specially since we are talking about free software, and not some software that Microsoft can preinstall on your laptop.
      - bayindirh 2y ago
        Just because it has been pushed by RedHat and others are semi-forced to adapt, it doesn't mean all distros got in line to get a copy of the software and get it adopted. Pulse has been replaced with the pipewire as soon as it arrived, for example.
jimrandomh 3y ago
Setuid is a mechanism where you take a program, and mark it so it always runs as root (or some other user, but in this case root). The idea is that an unprivileged user can run a setuid program, and the program itself decides what privileges to allow. The problem is that the user controls the program's view of the filesystem, environment variables, and other attributes, and this is an attack surface that can be used to trick it into loading and running code provided by the unprivileged user, which runs as root. For example, ordinary programs have a preamble inserted by the compiler where they load a programming-language runtime, usually from somewhere like /usr/lib; but a setuid program can't safely do this, because the user could use a chroot to replace /usr/lib with something different. In practice, this means that writing a setuid program correctly is exceptionally difficult and error prone, can only be done in C, and imposes security requirements on the compiler flags/makefiles rather than the source code, which creates a large risk of distro- or compiler-specific vulnerabilities. In practice, sudo is the only program people allow to use the setuid mechanism, and sudo is a unique and dangerous snowflake.
- kasabali 3y ago
  > because the user could use a chroot to replace /usr/lib with something different You need to be root in the first place to be able to do that

datadrivenangel 3y ago

SUID has flaws, but it's not clear that there are any more convenient alternatives?

1oooqooq 3y ago
you missed the memo. it's dbus. (wish i could end with /s)
semi 3y ago
it depends on what you're needing suid for but the first thing id evaluate is if you can just grant a specific CAPAB instead.

bayindirh 3y ago

SUID mechanism doesn’t always “elevate to root”. It’s a mechanism to “run as another user” and with SGID allows great flexibility in user permission management. You can allow all kinds of (responsible) user switch tricks for multi-admin servers and multi-user systems. Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture. Moreover, removing SUID breaks tons of mechanisms and scenarios. Security of sudo can be debated, but evolving current sudo to a better state step by step is miles better than banishing and rebuilding it and making it dependent on systemd + polkit. systemd already breaks tons of UNIX conventions and way more complicated than it should be. When you think, it sounds like “conquering” another part of user space mixed with NIH (and we know the best), and making systemd more entrenched. systemd is already a pretty large surface area to attack to begin with. XZ back door reached SSHd over libaystemd. Do we need another “integrated target” to attack in Linux?

crabbone 3y ago
All these ideas that tie permissions to a file completely fail when files need to be accessed either over network, or inside a container. I can see how the original authors didn't consider these cases, because they simply weren't there yet... but knowing what we know today: SUID is an awful idea.
- bayindirh 3y ago
  Sorry for my ignorance, but what’s a scenario that you run a SUID/GUID binary from a network or a container? If you access and run, it’s SSH or similar, so it works on the system scope. If it’s a container built correctly, it has its own users and isolation already, so it shouldn’t be able to fire any binary on your “base” system, and any effect is already in the container scope. I have never had the need to SUID/GUID a non executable, and didn’t need to trigger something on the system inside a container in the last ~20 years.
  - crabbone 3y ago
    > but what’s a scenario that you run a SUID/GUID binary from a network or a container? A lot of publicly available container images require elevated permissions to simply function, not for anything extraordinary. So, the user in container needs to be a superuser. It's often even not to perform the program's main function, but because various ordinary things in Linux require elevated permissions. > container built correctly That's a spherical horse in vacuum. If you write code s.t. there aren't any errors, you don't need to do error handling, right? You don't get to choose how containers are built. You need to deal with all possibilities of how containers can be built. Network filesystem? -- /usr/shared, /usr/opt and /usr/local? That's by design... very typical for cluster management software to mount these from NAS. It's also very not typical to keep these as "only text files". Pretty sure a lot of Google's stuff installs automatically into /usr/shared. I think even Go compiler and other infra at some point was being installed there by default. Finally: the same argument as with containers. You, for some reason, are trying to fantasize the world where problems don't exist because you chose the world w/o problems. But this isn't the real world. It's a fantasy. In real world, with or without reason, programmers and other computer users will do what's possible, not what you want them to do.

lucideer 3y ago

The problem with this line of thinking is it gives automatic carte blanche to anyone pointing out problems to implement "solutions" to those problems with little interrogation of whether those solutions are actually better. SUID, like any system, is flawed. Most of those flaws are balanced trade-offs; if you're addressing one you need to be aware of the severity of any counter-problems you're inevitably introducing. Lennart is well known for criticising existing systems while simultaneously ignoring & dismissing criticism of the proposed solutions - you need to be able to weigh up both sides in a balanced way. Lennart demonstrably isn't.

panick21_ 3y ago
> you need to be able to weigh up both sides in a balanced way. Lennart demonstrably isn't. That's why nobody uses his software. I mean just nothing he does gets adopted. The 'run0' solution uses an already existing mechanism that is already used for a lot of things.
- lucideer 2y ago
  > nobody uses his software Yes, you're absolutely right. Popularity is the best indicator of quality.
  - panick21_ 2y ago
    Its not the best indicator but to claim its meaningless is idiotic. Specially since we are talking about free software, and not some software that Microsoft can preinstall on your laptop.
    - bayindirh 2y ago
      Just because it has been pushed by RedHat and others are semi-forced to adapt, it doesn't mean all distros got in line to get a copy of the software and get it adopted. Pulse has been replaced with the pipewire as soon as it arrived, for example.

jimrandomh 3y ago

Setuid is a mechanism where you take a program, and mark it so it always runs as root (or some other user, but in this case root). The idea is that an unprivileged user can run a setuid program, and the program itself decides what privileges to allow. The problem is that the user controls the program's view of the filesystem, environment variables, and other attributes, and this is an attack surface that can be used to trick it into loading and running code provided by the unprivileged user, which runs as root. For example, ordinary programs have a preamble inserted by the compiler where they load a programming-language runtime, usually from somewhere like /usr/lib; but a setuid program can't safely do this, because the user could use a chroot to replace /usr/lib with something different. In practice, this means that writing a setuid program correctly is exceptionally difficult and error prone, can only be done in C, and imposes security requirements on the compiler flags/makefiles rather than the source code, which creates a large risk of distro- or compiler-specific vulnerabilities. In practice, sudo is the only program people allow to use the setuid mechanism, and sudo is a unique and dangerous snowflake.

kasabali 3y ago
> because the user could use a chroot to replace /usr/lib with something different You need to be root in the first place to be able to do that