Live data from Hacker News

SSH as a Sudo Replacement

whynothugo.nl

61–70 of 114 posts

Re: SSH as a Sudo Replacement

#61
post #44
post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Maybe also make /usr/bin/sudo immutable? would that help prevent a package manager from messing with it? I think so.

The downside of this is that if you have your system set up to automatically install package updates, then it will start failing, which might kill all automatic updates.

On Debian, for example, I have unattended-upgrades set up to automatically install security updates. sudo is reasonably likely to have updates for security reasons.

Re: SSH as a Sudo Replacement

#62
post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Pardon my ignorance, but I have to ask for explanation of what the wheel group is and does. I'm aware that this might open a can of worms.

The wheel group is just a regular user group, its just the name Debian gives the group with admin permissions.

It's no different to any other user group on linux systems and you could replace the name wheel with admin, freethinker, systemdestroyer or whatever else you wanna call it.

Re: SSH as a Sudo Replacement

#63
post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Pardon my ignorance, but I have to ask for explanation of what the wheel group is and does. I'm aware that this might open a can of worms.

Not really! In modern Linux specifically it's just a regular user group, but it's the de-facto standard name of the "administrator" group - users who can escalate to root privileges.

You might not even have wheel anymore; Debian just calls it "sudo" now.

Re: SSH as a Sudo Replacement

#64
post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Pardon my ignorance, but I have to ask for explanation of what the wheel group is and does. I'm aware that this might open a can of worms.

In addition to being the default name for the admin group in Debian, the name has some history:

> [from slang ‘big wheel’ for a powerful person] A person who has an active wheel bit. “We need to find a wheel to unwedge the hung tape drives.” The traditional name of security group zero in BSD (to which the major system-internal users like root belong) is ‘wheel’.

> The term was invented on the TENEX operating system, and carried over to TOPS-20, XEROX-IFS, and others. The state of being in a privileged logon is sometimes called wheel mode. This term entered the Unix culture from TWENEX in the mid-1980s and has been gaining popularity there (esp. at university sites).

http://www.catb.org/~esr/jargon/html/W/wheel.html

Re: SSH as a Sudo Replacement

#65
post #59

Earlier quoted context omitted.

> Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them. That's very sensible, I wonder why it's not the default setup everywhere.

Probably because there's nothing that says only users in wheel (assuming your OS/distro even has that group; some don't) can sudo. You can grant any user with any group membership access to sudo, either full access, or restricted to only certain commands. If the package was set up to install /usr/bin/sudo so it was only runnable by members of the wheel group, that wouldn't work.

It's worth noting that the reason why your OS/distro doesn't have or doesn't respect wheel is largely down to RMS opposing it[0], instead favoring people trading the root password around to unauthorized users.

[0] https://web.archive.org/web/20070603191229/http://www.gnu.or...

Re: SSH as a Sudo Replacement

#66
post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

> Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them. That's very sensible, I wonder why it's not the default setup everywhere.

Not every user who uses sudo is admin or elevates to root.

Re: SSH as a Sudo Replacement

#67
This is not a solution, it's a workaround. One that breaks with ( outdated ) system design doctrines and therefore is likely to spawn more cans of worms and will certainly increase the amount of technical debt at present.

Re: SSH as a Sudo Replacement

#68
post #59

Earlier quoted context omitted.

Probably because there's nothing that says only users in wheel (assuming your OS/distro even has that group; some don't) can sudo. You can grant any user with any group membership access to sudo, either full access, or restricted to only certain commands. If the package was set up to install /usr/bin/sudo so it was only runnable by members of the wheel group, that wouldn't work.

It's worth noting that the reason why your OS/distro doesn't have or doesn't respect wheel is largely down to RMS opposing it[0], instead favoring people trading the root password around to unauthorized users. [0] https://web.archive.org/web/20070603191229/http://www.gnu.or...

It's also worth noting that the Coreutils `su` is no longer in use by anyone, and that the `su` from the shadow-package absolutely checks for wheel. It's even configurable if you haven't enabled PAM by configuring `SU_WHEEL_ONLY` in your login.defs. And with PAM you configure that via PAM.

Hell, not even GNU distros like GNU Guix, Parabola, nor Trisquel follow RMS' opinions on this anymore.

Re: SSH as a Sudo Replacement

#69
post #44
post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Maybe also make /usr/bin/sudo immutable? would that help prevent a package manager from messing with it? I think so.

[deleted]

Re: SSH as a Sudo Replacement

#70
post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

> And since the sshd approach doesn't allow you to restrict root access to only certain commands [...]

The ForcedCommand infrastructure.

Post reply on HN