5 ms·

Which parts are you thinking of removing? The goal is “to build a drop-in replacement for all common use cases of sudo” so the doas comparison doesn’t really fo

Which parts are you thinking of removing? The goal is “to build a drop-in replacement for all common use cases of sudo” so the doas comparison doesn’t really follow. The fabulous article mentions that, “sudo-rs only has 3 dependencies in its dependency graph” so maybe they could trade loc for deps but that doesn’t seem wise to me. The audit found one moderate path traversal vulnerability which was also present in og sudo, so I’m not sure how your suggestion could be made practical.

codetrotter 3y ago
> the doas comparison doesn’t really follow The real question is, do you really need everything that sudo can do? Or would doas be sufficient? On my FreeBSD servers, I install doas instead of sudo, and I have never once found myself missing any features in spite of having completely replaced sudo with doas on my FreeBSD servers. Replaced as in, I no longer even have sudo installed on my FreeBSD servers. I switched from sudo to doas cold turkey years ago and haven’t looked back. (On Linux I still use sudo, but that is simply because it comes pre-installed on the Linux distros I use so I haven’t bothered to install doas instead there.) doas does exactly what I need; run the following command as root.
- eep_social 3y ago
  Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. But as I said elsethread, I’m also very interested in an as-safe-as-possible replacement between now and then. Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes. Could it be done within POSIX? IDK but I’d guess not.
  - cedws 3y ago
    >Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes A sort of workaround is that you can log in as the desired user from a TTY. Of course, this gets tricky if you don't have physical access or a remote serial connection. And you probably wouldn't want to log in as root over SSH. I don't have real solutions in mind but it's ticking over in my head. Might have some ideas later on.
    - eep_social 3y ago
      Aye, but then we are (I think) sharing credentials so we can both log in as the user with specific (read: elevated) permissions, and we lose any ability to know who the “real” person-user is on top. So it’s a different problem and we’re starting to talk about threat models and such..
      - cedws 3y ago
        > we lose any ability to know who the “real” person-user is on top It's a complex topic probably best suited for discussion elsewhere, but do we even need to discern that anymore? Statistically most Linux systems running now are single-seat (as in, one real user). A big corp with thousands of servers and employees might want to know this stuff for audit logging, but if employees have root access, they can already fake everything at ring 3. Big corps use security software that do that stuff in ring 0.
        e12e 3y ago
        > if employees have root access The main usecase of sudo over su (or suid binaries) is limited access (clear/re-run the mail queue - not reconfigure the mail daemon)
  - yjftsjthsd-h 3y ago
    > Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. Not that heavy a lift, at least as a default. AIUI Alpine switched to doas and moved sudo to the community repo, Arch supports both, Void supports both, and NixOS supports both. I wouldn't be surprised if there are more. Although, RHEL and SUSE would probably have a harder time because their customers are more likely to use sudo's long tail of features.
    - eep_social 3y ago
      I’m only vaguely aware of Alpine but that’s pretty neat!
- inferiorhuman 3y ago
  On FreeBSD the only thing I miss from sudo is the credential caching. I believe opendoas uses the same fairly portable method that sudo does. doas uses an OpenBSD-specific API.
- e12e 3y ago
  Users and groups (auth/autz) via kerberos/ldap/active directory? Radius? Not something "most users" would need - and probably handled in Pam, not sudo - but it's one thing that comes to mind.
cedws 3y ago
>Which parts are you thinking of removing? All of it. Seriously. doas demonstrates that sudo's primary function (running commands as another user) can be achieved in an order of magnitude less code and a significantly smaller attack surface. 90% of people don't need more than that, they don't need all the bells and whistles that sudo offers. We aren't in the 90s running on mainframes anymore. As an aside, doas and sudo are conceptually broken from a security POV because the user's shell can be played with to elevate privileges. The real fix is dump doas and sudo entirely.
- eep_social 3y ago
  > conceptually broken I agree, but the goal of this particular project is to make sudo as safe as possible. Within the stated goal, I don’t think significant LOC reduction is a feasible side quest. Evangelizing the removal of sudo entirely is an interesting thought but given how widely deployed it is, I see a ton of value in having a sudo-rs stopgap between now and then.
  - cedws 3y ago
    Sorry, yes, I think this work is useful, but I also think that sysadmins and distro maintainers should be starting to think about dropping sudo in favour of something simpler. Those who need sudo can still reach for it.
- joelthelion 3y ago
  > As an aside, doas and sudo are conceptually broken from a security POV because the user's shell can be played with to elevate privileges. The real fix is dump doas and sudo entirely. Could you elaborate on this?
technion 3y ago
I think the one moderate vulnerability is an example of this. I have serious doubts about anyone having wanted to use that remove timestamps parameter in 2023. I'd be surprised if many people know it exists. I more surprised an os would let you make a user with "../../" in the name though. I'd bet a heap of things would break. A while back I saw a guy name his windows desktop with an emoji and all sorts of software fell over.
- Karellen 3y ago
  > I more surprised an os would let you make a user with "../../" in the name though. There may be protections at some levels, but eventually a username is just an entry in a database. Admittedly, you do have to be on the other side of the airtight hatchway to do it, but modifying a line in /etc/passwd to have the field before the first ":" be "../../" is something the os can't really do much about once it's there.
- eep_social 3y ago
  Funny enough, my iphone has an emoji-only name and everything seems to work. I haven’t dared try with a machine I might want to ssh into though.
  - pixl97 3y ago
    An emoji SSID can be hit and miss at times on what can detect it.
    - eep_social 3y ago
      This is the actual device name, not just the network but that’s a good point. Tethering via the network manager GUI from a macbook works as expected with the network name same as device. You got me curious so I checked arp -a which shows host name as a ?. Nmap also isn’t able to resolve the emoji name, neither is host, and I don’t think dns-sd either, though my mdns-fu is poor. I did test Terminal.app and I can echo an emoji so I’m guessing this is mostly a limitation of some of the ancient bsd utils that are packed with macos. Thanks for the little rabbit hole!

codetrotter 3y ago

> the doas comparison doesn’t really follow The real question is, do you really need everything that sudo can do? Or would doas be sufficient? On my FreeBSD servers, I install doas instead of sudo, and I have never once found myself missing any features in spite of having completely replaced sudo with doas on my FreeBSD servers. Replaced as in, I no longer even have sudo installed on my FreeBSD servers. I switched from sudo to doas cold turkey years ago and haven’t looked back. (On Linux I still use sudo, but that is simply because it comes pre-installed on the Linux distros I use so I haven’t bothered to install doas instead there.) doas does exactly what I need; run the following command as root.

eep_social 3y ago
Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. But as I said elsethread, I’m also very interested in an as-safe-as-possible replacement between now and then. Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes. Could it be done within POSIX? IDK but I’d guess not.
- cedws 3y ago
  >Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes A sort of workaround is that you can log in as the desired user from a TTY. Of course, this gets tricky if you don't have physical access or a remote serial connection. And you probably wouldn't want to log in as root over SSH. I don't have real solutions in mind but it's ticking over in my head. Might have some ideas later on.
  - eep_social 3y ago
    Aye, but then we are (I think) sharing credentials so we can both log in as the user with specific (read: elevated) permissions, and we lose any ability to know who the “real” person-user is on top. So it’s a different problem and we’re starting to talk about threat models and such..
    - cedws 3y ago
      > we lose any ability to know who the “real” person-user is on top It's a complex topic probably best suited for discussion elsewhere, but do we even need to discern that anymore? Statistically most Linux systems running now are single-seat (as in, one real user). A big corp with thousands of servers and employees might want to know this stuff for audit logging, but if employees have root access, they can already fake everything at ring 3. Big corps use security software that do that stuff in ring 0.
      - e12e 3y ago
        > if employees have root access The main usecase of sudo over su (or suid binaries) is limited access (clear/re-run the mail queue - not reconfigure the mail daemon)
- yjftsjthsd-h 3y ago
  > Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. Not that heavy a lift, at least as a default. AIUI Alpine switched to doas and moved sudo to the community repo, Arch supports both, Void supports both, and NixOS supports both. I wouldn't be surprised if there are more. Although, RHEL and SUSE would probably have a harder time because their customers are more likely to use sudo's long tail of features.
  - eep_social 3y ago
    I’m only vaguely aware of Alpine but that’s pretty neat!
inferiorhuman 3y ago
On FreeBSD the only thing I miss from sudo is the credential caching. I believe opendoas uses the same fairly portable method that sudo does. doas uses an OpenBSD-specific API.
e12e 3y ago
Users and groups (auth/autz) via kerberos/ldap/active directory? Radius? Not something "most users" would need - and probably handled in Pam, not sudo - but it's one thing that comes to mind.

cedws 3y ago

>Which parts are you thinking of removing? All of it. Seriously. doas demonstrates that sudo's primary function (running commands as another user) can be achieved in an order of magnitude less code and a significantly smaller attack surface. 90% of people don't need more than that, they don't need all the bells and whistles that sudo offers. We aren't in the 90s running on mainframes anymore. As an aside, doas and sudo are conceptually broken from a security POV because the user's shell can be played with to elevate privileges. The real fix is dump doas and sudo entirely.

eep_social 3y ago
> conceptually broken I agree, but the goal of this particular project is to make sudo as safe as possible. Within the stated goal, I don’t think significant LOC reduction is a feasible side quest. Evangelizing the removal of sudo entirely is an interesting thought but given how widely deployed it is, I see a ton of value in having a sudo-rs stopgap between now and then.
- cedws 3y ago
  Sorry, yes, I think this work is useful, but I also think that sysadmins and distro maintainers should be starting to think about dropping sudo in favour of something simpler. Those who need sudo can still reach for it.
joelthelion 3y ago
> As an aside, doas and sudo are conceptually broken from a security POV because the user's shell can be played with to elevate privileges. The real fix is dump doas and sudo entirely. Could you elaborate on this?

technion 3y ago

I think the one moderate vulnerability is an example of this. I have serious doubts about anyone having wanted to use that remove timestamps parameter in 2023. I'd be surprised if many people know it exists. I more surprised an os would let you make a user with "../../" in the name though. I'd bet a heap of things would break. A while back I saw a guy name his windows desktop with an emoji and all sorts of software fell over.

Karellen 3y ago
> I more surprised an os would let you make a user with "../../" in the name though. There may be protections at some levels, but eventually a username is just an entry in a database. Admittedly, you do have to be on the other side of the airtight hatchway to do it, but modifying a line in /etc/passwd to have the field before the first ":" be "../../" is something the os can't really do much about once it's there.
eep_social 3y ago
Funny enough, my iphone has an emoji-only name and everything seems to work. I haven’t dared try with a machine I might want to ssh into though.
- pixl97 3y ago
  An emoji SSID can be hit and miss at times on what can detect it.
  - eep_social 3y ago
    This is the actual device name, not just the network but that’s a good point. Tethering via the network manager GUI from a macbook works as expected with the network name same as device. You got me curious so I checked arp -a which shows host name as a ?. Nmap also isn’t able to resolve the emoji name, neither is host, and I don’t think dns-sd either, though my mdns-fu is poor. I did test Terminal.app and I can echo an emoji so I’m guessing this is mostly a limitation of some of the ancient bsd utils that are packed with macos. Thanks for the little rabbit hole!