5 ms·

Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or

Right, but now the vector for privilege escalation will have to be a logic bug in memory-safe sudo instead of either a memory corruption (see CVE-2021-3156) or a logic bug. It’s hard not to see this as a major improvement.

charcircuit 1y ago
Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.
- jvanderbot 1y ago
  Those will also have to be fixed/considered, but do not detract from the contribution of removing memory safety bugs which may enable exploits.
  - charcircuit 1y ago
    This is a case of doubling down on bad design. To me it's wasted effort preventing theoretical bugs in niche setups.
    - a_t48 1y ago
      Even with a new, perfect paradigm, there would be billions of systems running sudo for years.
    - jvanderbot 1y ago
      I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")
      - charcircuit 1y ago
        Yes, it's more effort, but it's not close to being the same.
        pixl97 1y ago
        I mean moving from IPv4 to IPv6 is more effort, but it's not close to being the same... And it's also why it mostly has not happened for most people.
- im3w1l 1y ago
  I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates. You can enforce a boundary between root and an account that never elevates though. And as far as I understand hardening sudo helps with that.
  - charcircuit 1y ago
    >I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates. So stop doing that!
    - z3t4 1y ago
      What should you do instead?
      - charcircuit 1y ago
        Design the system so that you do not need users to escalate to root. Find each use case where a user may want to use sudo and then come up with an alternate way to accomplish that action from a regular account.
        lupusreal 1y ago
        We have that, it's called android. Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.
        charcircuit 1y ago
        Doing system updates is not off the beaten path.
        theamk 1y ago
        And system updates don't need sudo on desktops, it is not 1990's anymore... GUI apps like software-properties-gtk use dbus with polkit auth to upgrade software without any involvement of "sudo" or giving root access to users.
- hulitu 1y ago
  > Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate So does your OS.
- remram 1y ago
  I don't see how this attack is related to the setuid binary. No matter what method you provide to the user to elevate their privileges, they can be tricked into doing it. If it was provided by a daemon, built into systemd, or anything else, the problem would be the same.
  - charcircuit 1y ago
    It's related because malicous code can use the setuid binary to elevate its privileges. >If it was provided by a daemon, built into systemd, or anything else Yes, this is also dangerous.
    - remram 1y ago
      So what's your recommendation? Removing the user?
- zahlman 1y ago
  Do you have in mind a design that enables users to escalate privileges while preventing them from being tricked into escalating privileges?
h4ck_th3_pl4n3t 1y ago
A major improvement would be to get rid of glibc altogether. As long as glibc is the default, the problems persist.
- IshKebab 1y ago
  That is possible: https://github.com/sunfishcode/eyra https://github.com/sunfishcode/eyra

charcircuit 1y ago

Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate. Depending on how sudo authenticates phishing attacks or password reuse from another breach can be used to escalate privileges.

jvanderbot 1y ago
Those will also have to be fixed/considered, but do not detract from the contribution of removing memory safety bugs which may enable exploits.
- charcircuit 1y ago
  This is a case of doubling down on bad design. To me it's wasted effort preventing theoretical bugs in niche setups.
  - a_t48 1y ago
    Even with a new, perfect paradigm, there would be billions of systems running sudo for years.
  - jvanderbot 1y ago
    I think the opposing view is that moving away from sudo is substantially more effort and would break basically everything to accomplish "the same" thing as robustifying sudo (for some very loose definition of "same")
    - charcircuit 1y ago
      Yes, it's more effort, but it's not close to being the same.
      - pixl97 1y ago
        I mean moving from IPv4 to IPv6 is more effort, but it's not close to being the same... And it's also why it mostly has not happened for most people.
im3w1l 1y ago
I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates. You can enforce a boundary between root and an account that never elevates though. And as far as I understand hardening sudo helps with that.
- charcircuit 1y ago
  >I don't think you can realistically enforce a security boundary between root, and a user account that occasionally elevates. So stop doing that!
  - z3t4 1y ago
    What should you do instead?
    - charcircuit 1y ago
      Design the system so that you do not need users to escalate to root. Find each use case where a user may want to use sudo and then come up with an alternate way to accomplish that action from a regular account.
      - lupusreal 1y ago
        We have that, it's called android. Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.
        charcircuit 1y ago
        Doing system updates is not off the beaten path.
        theamk 1y ago
        And system updates don't need sudo on desktops, it is not 1990's anymore... GUI apps like software-properties-gtk use dbus with polkit auth to upgrade software without any involvement of "sudo" or giving root access to users.
hulitu 1y ago
> Being a setuid binary means that sudo also suffers from attacks where an attacker runs `sudo ./malware` and then convinces the user to authenticate So does your OS.
remram 1y ago
I don't see how this attack is related to the setuid binary. No matter what method you provide to the user to elevate their privileges, they can be tricked into doing it. If it was provided by a daemon, built into systemd, or anything else, the problem would be the same.
- charcircuit 1y ago
  It's related because malicous code can use the setuid binary to elevate its privileges. >If it was provided by a daemon, built into systemd, or anything else Yes, this is also dangerous.
  - remram 1y ago
    So what's your recommendation? Removing the user?
zahlman 1y ago
Do you have in mind a design that enables users to escalate privileges while preventing them from being tricked into escalating privileges?

h4ck_th3_pl4n3t 1y ago

A major improvement would be to get rid of glibc altogether. As long as glibc is the default, the problems persist.

IshKebab 1y ago
That is possible: https://github.com/sunfishcode/eyra https://github.com/sunfishcode/eyra