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

91–100 of 114 posts

Re: SSH as a Sudo Replacement

#91

Post by mmh0000 »

acka wrote: post #72
mmh0000 wrote: post #11

Earlier quoted context omitted.

If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed. Also, may I introduce you to the ‘sudo -i’ option.

> eMacs This made me chuckle. Apple influencing the way Emacs is capitalized (pun intended) versus RMS's stance on Free Software couldn't be further apart I think.

You're correct there! Wrote that up on my tiny Apple device and really couldn't be bothered to correct Apple's spellcheck. Text editing from a 5in touchscreen is very painful.

Re: SSH as a Sudo Replacement

#92

Post by krispyfi »

inopinatus wrote: post #53
guerby wrote: post #52

Earlier quoted context omitted.

Except when physically logged in via console you're already using ssh before using sudo. So the complexity you describe is already there. sudo removed is one less moving part in the end.

That is a furphy, because both tools are also used non-interactively. If you forced me to choose one to remove, I’d delete ssh in many cases. Anything production that isn’t bare-metal is a candidate for never allowing a remote terminal. Easiest with cloud instances since they’re almost completely disposable, but many sites still don’t have the stomach/discipline for it.

TIL: "furphy" https://en.m.wikipedia.org/wiki/Furphy

Re: SSH as a Sudo Replacement

#94

Post by kstrauser »

tankenmate wrote: post #76
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…

Personally I use etckeeper[0] to make sure all changes to /etc are tracked, either by software installs / upgrades, or done by humans. It's also great when needing to upgrade a machine to a newer release as you can create a patch file with all your local changes and apply that patch to a clean install and do a three way merge that will highlight all conflicts and keep you up to date and any changes required from one…

I like Chezmoi for this, and also use it to manage my home directory.

Plain ol’ git is also nice in a pinch.

Re: SSH as a Sudo Replacement

#95

Post by vbezhenar »

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…

If you could configure your linux kernel without suid support, that would be huge benefit for security, IMO. suid feature is huge security hole.

Whether fighting one particular suid binary worth it, is questionable indeed. But this is good direction. Another modern approach to this problem is run0 from systemd.

Re: SSH as a Sudo Replacement

#96

Post by westurner »

vbezhenar wrote: post #95
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…

If you could configure your linux kernel without suid support, that would be huge benefit for security, IMO. suid feature is huge security hole. Whether fighting one particular suid binary worth it, is questionable indeed. But this is good direction. Another modern approach to this problem is run0 from systemd.

"List of Unix binaries that can be used to bypass local security restrictions" (2023) https://news.ycombinator.com/item?id=36637980

"Fedora 40 Plans To Unify /usr/bin and /usr/sbin" (2024) https://news.ycombinator.com/item?id=38757975 ; a find expression to locate files with the setuid and setgid bits, setcap,

man run0: https://www.freedesktop.org/software/systemd/man/devel/run0....

Re: SSH as a Sudo Replacement

#97

Post by jeffhuys »

joveian wrote: post #87
aaaronic wrote: post #2

Am I missing something? How is logging into ssh (sshd) AS root more secure than using sudo? I honestly don’t even know how dangerous that is because I’ve always been told to never allow it. I see here thought goes into preventing that for a remote user, so I’m not talking about that aspect of security here. Maybe it has to do with #3 in the sudo limitations — I certainly don’t see any benefits vis-a-vis #1. I totally…

The big advantage is if setuid and setgid support can be entirely removed. There are a bunch of special cases that have been added over the years to try to deal but increasing priviledges of a process is fundamentally more challenging in the unix security model than only ever lowering priviledges. Of course these days Linux has priviledge escalation via user namespaces as well.

Psst… privilege has no letter D

Re: SSH as a Sudo Replacement

#98

Post by WD-42 »

kqr wrote: post #64
euroderf wrote: post #60

Earlier quoted context omitted.

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,…

Great bit of history, thanks!

Re: SSH as a Sudo Replacement

#99

Post by arp242 »

vbezhenar wrote: post #95
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…

If you could configure your linux kernel without suid support, that would be huge benefit for security, IMO. suid feature is huge security hole. Whether fighting one particular suid binary worth it, is questionable indeed. But this is good direction. Another modern approach to this problem is run0 from systemd.

> IMO. suid feature is huge security hole.

As opposed to running background processes as root...?

This is just mindless dogma at this point. You're going to need something to elevate permissions, and setuid is as good of a scheme as any. ssh or run0 are not magic and just as "vulnerable" as setuid or anything else. Any of these schemes are "security holes" if you abuse it.

Post reply on HN