6 ms·

Sudo has too much surface area for a suid utility IMHO, unnecessary pile of features, config parsing, etc. I still just use `su` with the wheel group membershi

Sudo has too much surface area for a suid utility IMHO, unnecessary pile of features, config parsing, etc. I still just use `su` with the wheel group membership executable requirement for gaining root privileges from my regular user. But sudo has become quite entrenched, almost every software deployment guide I see expects sudo, many scripts outright break on the assumption of sudo being present. Do you know the list of suid binaries installed on your machine? `find / -perm -4000 -printf '%#m %u %p\n'`

simcop2387 7y ago
The thing is, sudo also tries to allow you to give much more limited access also. Such as run specific commands as another user without needing full root access. That does present a larger surface on the part of sudo, but it's a considerably tiny surface compared to giving the user full access with su and wheel.
yjftsjthsd-h 7y ago
Yeah, I started using OpenBSD's doas and it's surprising how many things expect sudo specifically.
- tomrod 7y ago
  For the most part, could you alias doas to sudo?
  - jlgaddis 7y ago
    FWIW, I did exactly that on my OpenBSD machines when doas was first introduced and I can't think of any issues I've encountered.
  - yjftsjthsd-h 7y ago
    Maybe? The one that sticks out in my memory is running sshuttle on Arch Linux; Arch considers sudo to be part of the base group, so it doesn't want to remove the package, and I think sshuttle invokes /usr/bin/sudo with special options to control it. But... I might try just making a sudo symlink in my path and see how it behaves; thanks for the idea:)
jean23 7y ago
When all you have is a single user machine, and "gain root from my regular user" is all you want, su is enough. Yes, sudo has a few more features, but just because you don't need them doesn't mean they are necessarily "unnecessary". And if you look at the bug – that bug wouldn't have occurred in your setup. You could replicate the functionality where this bug occurs with sudo and pam, but I don't really think that's less "surface area", and I know the chance that I would muck up re-implementing sudo functionality that way with a greater chance than the sudo devs.
- newnewpdro 7y ago
  I use the same strategy on the multi-user shell machine I operate. The few trusted admins are in the wheel group, there's no root logins over ssh, and there's no sudo. The regular users don't get to switch users and definitely don't get access to root even if they know the root password since they're not members of wheel. Sudo has never seemed like a good idea to me, but I've never had the inclination to let some users do just some things as root. Most programs have ways to escape and get to a shell somehow, so relying on sudo to restrict access to specific programs is often fundamentally flawed because those programs themselves are more often than not incapable of restricting the user from escaping them with the elevated privs.
isostatic 7y ago
We have an ever changing group of about 60 engineers who need the ability to do rooty style things on about 500 different machines (very few of which are the same, so things like ansible don't work too well). While only a handful actually do, the rest need to be able to, and they're trusted to make the call. However we still want to know what's going on, and sudo fires back a message to syslog with who did it and what they did. Far more useful than "joebloggs went to root at 03:14 and logged out at 09:15"
- jlgaddis 7y ago
  If you take the time (once) to configure it correctly, auditd can tell you much, much more than just what commands were executed (and "hiding" the commands you ran via sudo is fairly trivial, if one is so inclined).
  - isostatic 7y ago
    Wouldn't that simply say "root did this at this time", and maybe "on this pts", and then I'd have to marry that up with who was logged on at the given pts at that time? Either way we don't sue sudo to enforce security -- anyone could go and reboot the machine physically in any case, we use sudo so we remember what we did, or can quickly find the person who did it. Same with physical security, we don't stop people from pulling the plug, but if the plug is pulled we can see who was probably in the room at the time. You can work around it (by going in with a colleague) if you wanted to hide your tracks, but people don't hide their tracks. Of course the other benefit of sudo is to reduce the number of terminals logged in as root, where accidents can easilly happen.

simcop2387 7y ago

The thing is, sudo also tries to allow you to give much more limited access also. Such as run specific commands as another user without needing full root access. That does present a larger surface on the part of sudo, but it's a considerably tiny surface compared to giving the user full access with su and wheel.

yjftsjthsd-h 7y ago

Yeah, I started using OpenBSD's doas and it's surprising how many things expect sudo specifically.

tomrod 7y ago
For the most part, could you alias doas to sudo?
- jlgaddis 7y ago
  FWIW, I did exactly that on my OpenBSD machines when doas was first introduced and I can't think of any issues I've encountered.
- yjftsjthsd-h 7y ago
  Maybe? The one that sticks out in my memory is running sshuttle on Arch Linux; Arch considers sudo to be part of the base group, so it doesn't want to remove the package, and I think sshuttle invokes /usr/bin/sudo with special options to control it. But... I might try just making a sudo symlink in my path and see how it behaves; thanks for the idea:)

jean23 7y ago

When all you have is a single user machine, and "gain root from my regular user" is all you want, su is enough. Yes, sudo has a few more features, but just because you don't need them doesn't mean they are necessarily "unnecessary". And if you look at the bug – that bug wouldn't have occurred in your setup. You could replicate the functionality where this bug occurs with sudo and pam, but I don't really think that's less "surface area", and I know the chance that I would muck up re-implementing sudo functionality that way with a greater chance than the sudo devs.

newnewpdro 7y ago
I use the same strategy on the multi-user shell machine I operate. The few trusted admins are in the wheel group, there's no root logins over ssh, and there's no sudo. The regular users don't get to switch users and definitely don't get access to root even if they know the root password since they're not members of wheel. Sudo has never seemed like a good idea to me, but I've never had the inclination to let some users do just some things as root. Most programs have ways to escape and get to a shell somehow, so relying on sudo to restrict access to specific programs is often fundamentally flawed because those programs themselves are more often than not incapable of restricting the user from escaping them with the elevated privs.

isostatic 7y ago

We have an ever changing group of about 60 engineers who need the ability to do rooty style things on about 500 different machines (very few of which are the same, so things like ansible don't work too well). While only a handful actually do, the rest need to be able to, and they're trusted to make the call. However we still want to know what's going on, and sudo fires back a message to syslog with who did it and what they did. Far more useful than "joebloggs went to root at 03:14 and logged out at 09:15"

jlgaddis 7y ago
If you take the time (once) to configure it correctly, auditd can tell you much, much more than just what commands were executed (and "hiding" the commands you ran via sudo is fairly trivial, if one is so inclined).
- isostatic 7y ago
  Wouldn't that simply say "root did this at this time", and maybe "on this pts", and then I'd have to marry that up with who was logged on at the given pts at that time? Either way we don't sue sudo to enforce security -- anyone could go and reboot the machine physically in any case, we use sudo so we remember what we did, or can quickly find the person who did it. Same with physical security, we don't stop people from pulling the plug, but if the plug is pulled we can see who was probably in the room at the time. You can work around it (by going in with a colleague) if you wanted to hide your tracks, but people don't hide their tracks. Of course the other benefit of sudo is to reduce the number of terminals logged in as root, where accidents can easilly happen.