14 ms·

For anyone with a modicum of C spending any amount of time in the sudo codebase, this isn't much surprise. It's the scariest piece of organically grown security

For anyone with a modicum of C spending any amount of time in the sudo codebase, this isn't much surprise. It's the scariest piece of organically grown security-sensitive code I'm aware of still in popular use. It's jam-packed with features you've never even heard of, and has quite surprising functional changes across versions that never make the changelog and require diffing to discover. It's hard to quantify that "this code is obviously wrong" feeling, for example liberal intermixing of concerns within a single procedure in many places of the code. Options with little to no security value (requiretty) documented as if they do, the ability to pass control to user-supplied policy plug-ins from a setuid binary, etc. There is just far too much going on to expect it not to regularly break Ignoring the implementation, I think it's fair to say sudo is broken in concept, simply by trying to have this kind of expressive policy language in the first place. The set of skills required to safely expose some subset of functionality to an untrustworthy user is perfectly distinct from those involved in typical sysadmin.

mehrdadn 7y ago
> Ignoring the implementation, I think it's fair to say sudo is broken in concept IMO you're not going far enough. The whole UNIX setuid notion is fundamentally broken to me. The ability to execute a file should logically have nothing to do with the permissions granted to you when doing so. Windows gets this right.
- iancarroll 7y ago
  How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.
  - minitech 7y ago
    Which UAC bypasses have they refused to fix?
    - mehrdadn 7y ago
      He's probably referring to [1], but he's wrong about UAC (note the sentence "UAC is not a security feature" on that post—the fact that he himself had to put quotes around "security" is itself telling), and moreover, I never claimed anything about UAC in the first place. He's ignoring my point and changing the topic, so I'm not inclined to reply. [1] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105 https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...
      - iancarroll 7y ago
        I don't know why this reply is so hostile, but I was curious what part of Windows you were referring to if not UAC, because I don't know of anything else. There is an almost comical list of bypasses in built-in AutoElevate programs that Microsoft does not triage as security bugs because as you note they don't call UAC a security feature. I think this is a rather silly deflection that users are unlikely to understand, for good reason.
        mehrdadn 7y ago
        I wasn't referring to a "part" at all. What I said Windows gets right was a very fundamental architectural design: the decision to not grant privileges to a process based on the file it's executing (the callee), but rather based on the caller's execution context. Note, in particular, that there was nothing in my comment that depended on the existence of UAC. Had I written my comment before UAC even existed (say, in the XP era), it would've been exactly the same. Yet somehow you managed to change the subject of discussion to a very specific feature UAC, a feature that was only introduced around the Vista era and which I had not even mentioned in my comment once. Then you bashed it based on a premise that you already knew was incorrect and therefore had to put in quotes, and then continued as if the point I had been making in my comment all along was to somehow endorse the use of this controversial feature I never mentioned for a purpose that it itself had not been intended. This is not a faithful representation of what I wrote.
    - johnisgood 7y ago
      I have no idea what he is referring to but being able to "Run as Administrator" as any user is sketchy.
- nray 7y ago
  > Windows gets this right. _If_ you turn it all the way up. The default setting "3" allows certain "approved" apps to be launched without the UAC prompt, based on what's in their manifest I think. Turn it up to "4" and it works as expected. If you're looking for a quick way to elevate the Explorer shell, run `hh \` (the Html Help viewer) from an elevated prompt.
- tannhaeuser 7y ago
  What is broken about setuid/setgid? Of course today we have eg SELinux, AppArmor, capsicum and other more sophisticated means, but still the basic setuid mechanism is sound: if you need access to privileged files, you can do so only via trusted setuid programs that only an admin or owner of said privileged file can setup with the setuid bit.
throwaway2048 7y ago
OpenBSD became concerned about sudo's codebase some time ago, and replaced it with the conceptually much simpler doas, which achives about 95% of what sudo does in real world usage. https://man.openbsd.org/doas https://man.openbsd.org/doas
- gilgamesh3 7y ago
  I've heard of doas sometimes and it's much simpler than sudo, but it's powerful. Doas has two non-official port for Linux[0][1], but it would be great if someone developed an official tool like doas for Linux. [0] https://github.com/multiplexd/doas https://github.com/multiplexd/doas [1] https://github.com/slicer69/doas https://github.com/slicer69/doas
- earenndil 7y ago
  Doas is very nice. I would like to use it on linux, but it only supports credential caching on openbsd.

mehrdadn 7y ago

> Ignoring the implementation, I think it's fair to say sudo is broken in concept IMO you're not going far enough. The whole UNIX setuid notion is fundamentally broken to me. The ability to execute a file should logically have nothing to do with the permissions granted to you when doing so. Windows gets this right.

iancarroll 7y ago
How does Windows get it right? Windows has User Account Control for UI apps, which is a “security” feature that they refuse to fix bypasses in.
- minitech 7y ago
  Which UAC bypasses have they refused to fix?
  - mehrdadn 7y ago
    He's probably referring to [1], but he's wrong about UAC (note the sentence "UAC is not a security feature" on that post—the fact that he himself had to put quotes around "security" is itself telling), and moreover, I never claimed anything about UAC in the first place. He's ignoring my point and changing the topic, so I'm not inclined to reply. [1] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105 https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...
    - iancarroll 7y ago
      I don't know why this reply is so hostile, but I was curious what part of Windows you were referring to if not UAC, because I don't know of anything else. There is an almost comical list of bypasses in built-in AutoElevate programs that Microsoft does not triage as security bugs because as you note they don't call UAC a security feature. I think this is a rather silly deflection that users are unlikely to understand, for good reason.
      - mehrdadn 7y ago
        I wasn't referring to a "part" at all. What I said Windows gets right was a very fundamental architectural design: the decision to not grant privileges to a process based on the file it's executing (the callee), but rather based on the caller's execution context. Note, in particular, that there was nothing in my comment that depended on the existence of UAC. Had I written my comment before UAC even existed (say, in the XP era), it would've been exactly the same. Yet somehow you managed to change the subject of discussion to a very specific feature UAC, a feature that was only introduced around the Vista era and which I had not even mentioned in my comment once. Then you bashed it based on a premise that you already knew was incorrect and therefore had to put in quotes, and then continued as if the point I had been making in my comment all along was to somehow endorse the use of this controversial feature I never mentioned for a purpose that it itself had not been intended. This is not a faithful representation of what I wrote.
  - johnisgood 7y ago
    I have no idea what he is referring to but being able to "Run as Administrator" as any user is sketchy.
nray 7y ago
> Windows gets this right. _If_ you turn it all the way up. The default setting "3" allows certain "approved" apps to be launched without the UAC prompt, based on what's in their manifest I think. Turn it up to "4" and it works as expected. If you're looking for a quick way to elevate the Explorer shell, run `hh \` (the Html Help viewer) from an elevated prompt.
tannhaeuser 7y ago
What is broken about setuid/setgid? Of course today we have eg SELinux, AppArmor, capsicum and other more sophisticated means, but still the basic setuid mechanism is sound: if you need access to privileged files, you can do so only via trusted setuid programs that only an admin or owner of said privileged file can setup with the setuid bit.

throwaway2048 7y ago

OpenBSD became concerned about sudo's codebase some time ago, and replaced it with the conceptually much simpler doas, which achives about 95% of what sudo does in real world usage. https://man.openbsd.org/doas https://man.openbsd.org/doas

gilgamesh3 7y ago
I've heard of doas sometimes and it's much simpler than sudo, but it's powerful. Doas has two non-official port for Linux[0][1], but it would be great if someone developed an official tool like doas for Linux. [0] https://github.com/multiplexd/doas https://github.com/multiplexd/doas [1] https://github.com/slicer69/doas https://github.com/slicer69/doas
earenndil 7y ago
Doas is very nice. I would like to use it on linux, but it only supports credential caching on openbsd.