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.<p>It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if there's a bug in it, an unauthorized user might be able to use it for privilege escalation. If that's really the main issue, then you can:<p><pre><code> chgrp wheel /usr/bin/sudo
chmod o-rwx /usr/bin/sudo
</code></pre>
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. This essentially gives you the same access-related security as the sshd approach (the UNIX socket there is set up to be only accessible to users in wheel), with much much much less complexity.<p>And since the sshd approach doesn't allow you to restrict root access to only certain commands (like sudo does), even if there is a bug in sudo that allows a user to bypass the command restrictions, that still gives no more access than the sshd approach.<p>If you are worried about your system package manager messing up the permissions on /usr/bin/sudo, you can put something in cron to fix them up that runs every hour or whatever you're comfortable with. Or you can uninstall sudo entirely, and manually install it from source to some other location. Then you have to maintain and upgrade it, manually, of course, unfortunately.
Isn't this what systemd run0 is now doing?<p><pre><code> There's a new tool in systemd, called "run0". Or actually, it's not a new tool, it's actually the long existing tool "systemd-run", but when invoked under the "run0" name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it's *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user's UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).
One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways.
</code></pre>
- <a href="https://mastodon.social/@pid_eins/112353324518585654" rel="nofollow">https://mastodon.social/@pid_eins/112353324518585654</a>
Am I missing something?<p>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.<p>Maybe it has to do with #3 in the sudo limitations — I certainly don’t see any benefits vis-a-vis #1.<p>I totally get that this is an experiment, but I suspect it is more vulnerable than using sudo, not less (the open socket proxy looks interestingly vulnerable to a man in the middle attack).<p>Having said all that, I did learn some tricks old tools are capable of, so kudos for showing me something new.
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.
I think it’s a bit remiss to not include all of the downsides of this approach. sudo allows control over which groups can exercise which commands, what args those commands accept, subshell spawns, etc, etc, etc.<p>This approach loses a lot of this fine-grained control, and also relies on trusted keys, which are harder to manage than editing a sudoers file.<p>To see all the amazing things that sudo can do, I’d really recommend the Sudo Mastery book.
This is a similar idea to run0 by Systemd: <a href="https://news.itsfoss.com/systemd-run0/" rel="nofollow">https://news.itsfoss.com/systemd-run0/</a>
One of the issues with ssh is that spawning processes isn't part of the protocol. And it's a remote protocol, so it can't pass local resources to the child. So you can't pass a null-separated array of arguments, pass extra file descriptors or specify an executable.
Instead it just passes a string to a server-configured shell. So you need to shell-escape things and know which shell is running on the server side.<p>To use SSH as a proper sudo replacement it'd need something closer to posix_spawn as an extension.
100 000 times yes: I do something similar and I described that here on HN in a comment / comments in the past!<p>The way I do is a bit different...<p>I'm using a dedicated machine as my physical "SSH console" and that machine is living on a private LAN which is separated from the rest of the machines at home. It's on an unmanaged switch, using ethernet cables (but no trunk).<p>Then the only way to login is using SSH but, here's a little spin... <i>with a Yubikey</i>.<p>The desktop PC has its own firewall, only accepting SSH traffic in from the IP / MAC address of my "SSH console" (on the private LAN it's sharing with the SSH console... On the other physical LAN, my desktop can access the Internet).<p>Then the <i>sshd</i> daemon is configured to only allow pub/priv key logins, no password logins.<p>So basically when I need root, I boot up my "SSH console" (which boots ultra quickly for there's basically nothing on that machine), log in, hit the up arrow to get back the "ssh root@..." line, hit enter, press the Yubikey.<p>That "ssh console" and its keyboard is on my desk, always withing reaching distance.<p>iptables/nftables (on a private LAN moreover, physically separated from the other private LAN) + sshd: you judge if this is more or less secure than sudo binaries / su.<p>As to the "why", I'd answer "because I can". I did set that up such a long time ago that I don't even remember when I did. I think I started toying with that idea two years ago and I've been using it ever since. Zero problem. Not a single issue.
This is an elegant solution to the problem. We don't need to treat users as children, but at the same time we should avoid potential foot guns with sensible defaults. I'd argue that even `su` is not needed, if you need to be root, then login as root via console. This is as close as possible to logging into root from the console tty.
I did something similar a decade ago (well without the UNIX socket bit, but just a separate sshd listening on localhost only and also no need to deal with SCM_RIGHTS). Nothing good or bad came out of it. I simply got bored and didn't bother porting this setup to the next machine.
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.
> I changed the root password<p>If you're going to set a root password, you might as well just do this and if I'm not mistaken it accomplishes everything you want<p><pre><code> alias sudo="su -c"</code></pre>
One issue I see with this is Single User Mode (aka recovery mode in grub (or similar) boot loader). Now you can't login as root to recover from init (systemd) configuration issues without having alternate boot media to get you access. I know it might sound pedantic but I used just this feature two days ago while upgrading a machine to a newer Linux release (the upgrade introduced an issue with the systemd / netplan config that got systemd into a loop due to deprecated keywords in the netplan config).
Good stuff. Imagine this though: ssh as user access control using a multiuser system such as gnu/linux<p>byw everyone should be using ed25519 or at least 2048+
I've used ssh to localhost as a hack for a backup-to-external-drive script (using Borg iirc) where I wanted the source reading and backup writing to be done as different users. There may have been a more elegant solution but it worked well enough
Usenix LISA (now called SRECon) had a paper about this technique in 2004:<p><a href="https://www.usenix.org/legacy/publications/library/proceedings/lisa04/tech/napier.html" rel="nofollow">https://www.usenix.org/legacy/publications/library/proceedin...</a><p>Those who ignore Usenix are doomed to repeat it … 20 years later.