Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH as a Sudo Replacement

whynothugo.nl

Post reply on HN
Print view View original

41–50 of 114 posts

Re: SSH as a Sudo Replacement

#41

Post by alexey-salmin »

TacticalCoder wrote: post #31
cycomanic wrote: post #18

So what happens if ssh (IIRC correctly in typical configurations it depends on network to start) fails to start at boot? You can't even login at failsave console. What does this actually buy us over sudo or su? Sure you avoid a setuid binary but instead you are now running a network service (even though only connected to a socket) with root priveledges.

As I run a system similar to the one used in TFA I'll give my take... > So what happens if ssh (IIRC correctly in typical configurations it depends on network to start) fails to start at boot? I do this for my main desktop. If the worse of the worse happen, I've got backup of everything (we all do right?) and I re-install the system. What I mean is: what do you do when you SSD is dead? You can't even login at failsaf…

> Much harder to pull local privilege escalation exploits.

That's not certain. sshd is way bigger than sudo, so chances of it having an exploitable bug seem higher.

Re: SSH as a Sudo Replacement

#42

Post by cqqxo4zV46cp »

alexey-salmin wrote: post #40
kelnos wrote: 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.

It’s at the very least incompatible with *some^ hypothetical sudo configurations. It’s probably a good hardening practice if you know how sudo is going to set up on the machine.

Re: SSH as a Sudo Replacement

#43

Post by gizmo686 »

cycomanic wrote: post #18

So what happens if ssh (IIRC correctly in typical configurations it depends on network to start) fails to start at boot? You can't even login at failsave console. What does this actually buy us over sudo or su? Sure you avoid a setuid binary but instead you are now running a network service (even though only connected to a socket) with root priveledges.

If you have access to the bootloadet, you can still set systems.unit=emergency.target, or init=/bin/bash, or rd.break=pre-pivot, or boot into a live-cd environment. All of the normal emergency options work.

For less fatal emergencies, I don't see anything that would tie this instance of sshd to tge network.

Re: SSH as a Sudo Replacement

#44

Post by lttlrck »

kelnos wrote: 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.

Re: SSH as a Sudo Replacement

#45

Post by rascul »

alexey-salmin wrote: post #40
kelnos wrote: 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.

I've seen a wheel or sudo group often enough to think it's common.

Re: SSH as a Sudo Replacement

#46

Post by rascul »

immibis wrote: post #25
bdd8f1df777b wrote: post #22

Earlier quoted context omitted.

That's extremely dangerous. Any software running as a wheel user can escalate privileges willy nilly.

they can also access your ssh private keys

In theory, those ssh private keys are password protected.

In practice, maybe not.

Re: SSH as a Sudo Replacement

#47

Post by ec109685 »

lttlrck wrote: post #44
kelnos wrote: 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.

How would you do that?

Re: SSH as a Sudo Replacement

#48

Post by ec109685 »

immibis wrote: post #25
bdd8f1df777b wrote: post #22

Earlier quoted context omitted.

That's extremely dangerous. Any software running as a wheel user can escalate privileges willy nilly.

they can also access your ssh private keys

They were stored in the user’s yubikeys (or similar) in this example.

Re: SSH as a Sudo Replacement

#50

Post by vrotaru »

ec109685 wrote: post #47
lttlrck wrote: post #44

Earlier quoted context omitted.

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

How would you do that?

lsattr - for reading attributes chattr - for setting them

You need the `i` attribute. But this is filesystem dependent. Anyway protecting the `sudo` binary from package managers is a so-so idea.

Post reply on HN