20 ms·

SSH as a Sudo Replacement

230 points by legobeet 2y ago

aaaronic 2y ago
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 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). Having said all that, I did learn some tricks old tools are capable of, so kudos for showing me something new.
- op00to 2y ago
  A big part of sudo is that you should be running individual commands using sudo to increase auditability rather than simply running sudo bash or whatever.
  - aaaronic 2y ago
    I can agree with that, though admit to being guilty of using sudo bash far more often than I should. I honestly thought they’d be using ssh that way (single command at a time), though I’m still not sure to what security end.
    - mmh0000 2y ago
      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.
      - dns_snek 2y ago
        > If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed. Keep in mind that this is borderline impossible to enforce unless your goal is just to stop the most common ways of accidentally breaking the policy. A list of commands that allows breaking out into a full shell includes: less, apt, man, nano, wget & many more. https://gtfobins.github.io/#+shell https://gtfobins.github.io/#+shell
      - acka 2y ago
        > 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.
        mmh0000 2y ago
        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.
    - op00to 2y ago
      I sudo bash a lot as well. Some times I regret it when I try to figure out what the hell I did months ago. :)
  - kiririn 2y ago
    Auditd and pam_tty_audit can take care of all your auditing needs
    - op00to 2y ago
      Sure! All part of layered controls and reporting.
  - dmw_ng 2y ago
    It's comical to see the sudo codebase mentioned in the same breath as increasing auditability here
- lmz 2y ago
  The sudo binary is suid root / privileged and is exposed directly to the untrusted user. If anything goes wrong inside of sudo (with the user's entire environment as the surface area), it may be exploited. The ssh approach does not expose a suid binary. Instead it uses the ssh network layer so it is no less secure than accessing ssh over a network, which is considered pretty secure.
  - hughesjj 2y ago
    ...why not just su then?
    - rpgwaiter 2y ago
      root would need a defined password, which opens up other security concerns
      - akira2501 2y ago
        Even if you allow passwordless su for users in the wheel group?
        djbusby 2y ago
        Do what!?
        bdd8f1df777b 2y ago
        That's extremely dangerous. Any software running as a wheel user can escalate privileges willy nilly.
        immibis 2y ago
        they can also access your ssh private keys
        rascul 2y ago
- o11c 2y ago
  I'm skeptical of the approach in the linked article, but: > I honestly don’t even know how dangerous that is because I’ve always been told to never allow it. You've fallen for the FUD. In reality, logging in directly as root over remote SSH is strictly more secure than logging in as user over remote SSH and then using `sudo`. If user@home uses ssh to root@server, then root@server is only compromised if user@home is compromised. If user@home uses ssh to user@server then sudo to root@server, then root@server is compromised if either user@home or user@server is compromised. In particular, it is fairly common for user@server to be running some other software such as daemons or cronjobs. Please don't give out free root escalation (and often lateral movement due to password reuse) to anyone who manages to infect through those! (This of course does not apply if sudo is used in whitelisted-commands-only mode and does not take either passwords or credentials fully accessible from the remote host)
  - cycomanic 2y ago
    I'm not sure I agree with this argument. Sure you can say theoretically it's one less account that could be compromised, but in practice I see a bunch of caveats. 1. If we allow password based logins, there will be many orders of magnitude more login attempts to root than any other user. So if you have to allow password based logins, you pretty much never want to allow root login. 2. If we disallow password based logins, a user account would be as save as a root login, except again that the root account is the much more valuable target so will get much more attention. I also do see the relevance of cronjobs (root does run them as well) and naturally no user that has sudo privileges should be be running network exposed services. 3. In cases were admin rights have to be shared amongst multiple users, are you going to share the same key for all users (probably not a good idea) or give every user a separate key (making key management a bit of a nightmare, user management is much easier). 4. As you pointed out yourself sudo gives you much more fine-grained control over commands that can be run.
    - kchr 2y ago
      > 3. In cases were admin rights have to be shared amongst multiple users, are you going to share the same key for all users (probably not a good idea) or give every user a separate key (making key management a bit of a nightmare, user management is much easier). To solve the key management nightmare, short-lived SSH certificates can be used to map an identity to a shared user account. Hashicorp Vault is one option for issuing such certificates, but there are other alternatives as well. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication https://docs.redhat.com/en/documentation/red_hat_enterprise_....
- fsniper 2y ago
  The approach is comparing - Theoretical configuration errors, or theoretical vulnerabilities that may or may not be there with - Having a new daemon running (a new attack surface) which - may also have configuration errors, or vulnerabilities as such - and also removes a few layers of user based authorisation with a single root level This approach is somehow considered more secure. And in a rational way, and of course for any rational security perspective this can't be considered more secure, just different.
- irusensei 2y ago
  > How is logging into ssh (sshd) AS root more secure than using sudo? Article describes an additional SSH server listening on an Unix socket. The usual threat model about exposing root logins from the internet may not apply here.
- joveian 2y ago
  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.
  - jeffhuys 2y ago
    Psst… privilege has no letter D
iroddis 2y ago
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. 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. To see all the amazing things that sudo can do, I’d really recommend the Sudo Mastery book.
- yjftsjthsd-h 2y ago
  SSH can do some of that with ForceCommand, though I agree that's not as flexible/precise.
hernantz 2y ago
This is a similar idea to run0 by Systemd: https://news.itsfoss.com/systemd-run0/ https://news.itsfoss.com/systemd-run0/
- ape4 2y ago
  And run0 isn't roll-your-own. Its audited and probably better than home grown.
mise_en_place 2y ago
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.
- bogantech 2y ago
  > if you need to be root, then login as root via console 1: This requires every user to have the root password, while sudo does not 2: If everyone just logs in as root there's no way to audit who actually logged in and did what.
  - kchr 2y ago
    Additionally, you need to rotate and distribute the new root password to all root users when you want to remove access for someone.
  - joveian 2y ago
    You can have multiple accounts with uid/gid 0 (and can set up smart card or u2f login too if you want).
xfitm3 2y ago
Fixing things that aren't broken. Changing things just because they can be changed. Sometimes boring and stagnant is good.
- irusensei 2y ago
  I wouldn’t go as far to say sudo is broken but have you considered why would people create things such as doas and run0 if sudo is good enough?
cycomanic 2y ago
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.
- jethro_tell 2y ago
  As far as I'm concerned, I use setuid/sudo for auditing. At this point, I don't really do multi-user/multi service boxes. Almost everything I have that's multi-tenant at this point is k8s and you can just use kubectl endpoint instead of ssh. But if you're allowed to log in, you're allowed to setuid to root. So for a k8s box, that's the platform infra team and access to the services on top is through the k8s permissions provider. For the platform infra teams, if you just need something like metrics and logs, that's already off box. If you need to trigger some job or workflow, you can use the pipeline. But when someone does log in and do root stuff, I want to have an audit log. I actually can't think of a single box I own where someone with a login doesn't also have root for everything. Obviously, I understand the services doing setuid thing, but in the case of services, you generally have systemd doing setuid to drop permissions instead of the other way around.
- CaliforniaKarl 2y ago
  > You can't even login at failsave console. Linux consoles (the ttys that appear over local display or remote-access KVM, or the ttyS* devices that appear over serial ports and IPMI SoL) do not use sudo or su. Those consoles use a program like `getty`, or a window-manager; all those programs are non-suid programs that are started as root. Your system should have a root password set, for logins via console.
  - TacticalCoder 2y ago
    > Your system should have a root password set, for logins via console. TFA says that he's prefixing his password hash with '!', making login with a root password impossible (including at the console). Hence GP's question.
TacticalCoder 2y ago
100 000 times yes: I do something similar and I described that here on HN in a comment / comments in the past! The way I do is a bit different... 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). Then the only way to login is using SSH but, here's a little spin... with a Yubikey. 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). Then the sshd daemon is configured to only allow pub/priv key logins, no password logins. 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. That "ssh console" and its keyboard is on my desk, always withing reaching distance. 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. 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.
- r4indeer 2y ago
  Sounds like what you have is similar to the idea of a bastion host, even if not quite the same.
ChoHag 2y ago
[dead]
kelnos 2y ago
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 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: chgrp wheel /usr/bin/sudo chmod o-rwx /usr/bin/sudo 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. 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. 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.
- alexey-salmin 2y ago
  > 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.
  - cqqxo4zV46cp 2y ago
    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.
  - rascul 2y ago
    I've seen a wheel or sudo group often enough to think it's common.
gnuser 2y ago
Good stuff. Imagine this though: ssh as user access control using a multiuser system such as gnu/linux byw everyone should be using ed25519 or at least 2048+
RecycledEle 2y ago
It seems like a way for Fed.Gov to know everything we do on our computers. Kill it with fire.
- RecycledEle 2y ago
  They have some rule hidden somewhere that communications through sockets is less private than things in the terminal.
kccqzy 2y ago
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.
coretx 2y ago
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.
ketily 2y ago
This reminds me a little of plam 9 and inferno in treating local resources and network resources with a uniform protocol
tankenmate 2y ago
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).
- joveian 2y ago
  If you want traditional single user mode that drops you to a root shell even though your root account is locked add SYSTEMD_SULOGIN_FORCE=1 to the environment of rescue.service and emergency.service (systemctl edit rescue.service). Of course that exact solution isn't always a good idea depending on the situation but in general that situation can be delt with differently from normal access while running correctly.
  - tankenmate 2y ago
    Ouch, that's a major security issue if configured that way. That's something I'll want to add to my hardening checks.
the8472 2y ago
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. To use SSH as a proper sudo replacement it'd need something closer to posix_spawn as an extension.
- jwilk 2y ago
  Bug report about the shell indirection: https://bugzilla.mindrot.org/show_bug.cgi?id=2283 https://bugzilla.mindrot.org/show_bug.cgi?id=2283
didntcheck 2y ago
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
YesThatTom2 2y ago
Usenix LISA (now called SRECon) had a paper about this technique in 2004: https://www.usenix.org/legacy/publications/library/proceedings/lisa04/tech/napier.html https://www.usenix.org/legacy/publications/library/proceedin... Those who ignore Usenix are doomed to repeat it … 20 years later.
prima-facie 2y ago
Isn't this what systemd run0 is now doing? 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. - https://mastodon.social/@pid_eins/112353324518585654 https://mastodon.social/@pid_eins/112353324518585654
- bandie91 2y ago
  why must systemd re-invent everything?
dheera 2y ago
> I changed the root password 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 alias sudo="su -c"
- philkrylov 2y ago
  Only with GNU su. A portable though limited replacement would be something like alias sudo="su root -c"

230 points by legobeet 2y ago

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 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). Having said all that, I did learn some tricks old tools are capable of, so kudos for showing me something new.

op00to 2y ago
A big part of sudo is that you should be running individual commands using sudo to increase auditability rather than simply running sudo bash or whatever.
- aaaronic 2y ago
  I can agree with that, though admit to being guilty of using sudo bash far more often than I should. I honestly thought they’d be using ssh that way (single command at a time), though I’m still not sure to what security end.
  - mmh0000 2y ago
    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.
    - dns_snek 2y ago
      > If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed. Keep in mind that this is borderline impossible to enforce unless your goal is just to stop the most common ways of accidentally breaking the policy. A list of commands that allows breaking out into a full shell includes: less, apt, man, nano, wget & many more. https://gtfobins.github.io/#+shell https://gtfobins.github.io/#+shell
    - acka 2y ago
      > 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.
      - mmh0000 2y ago
        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.
  - op00to 2y ago
    I sudo bash a lot as well. Some times I regret it when I try to figure out what the hell I did months ago. :)
- kiririn 2y ago
  Auditd and pam_tty_audit can take care of all your auditing needs
  - op00to 2y ago
    Sure! All part of layered controls and reporting.
- dmw_ng 2y ago
  It's comical to see the sudo codebase mentioned in the same breath as increasing auditability here
lmz 2y ago
The sudo binary is suid root / privileged and is exposed directly to the untrusted user. If anything goes wrong inside of sudo (with the user's entire environment as the surface area), it may be exploited. The ssh approach does not expose a suid binary. Instead it uses the ssh network layer so it is no less secure than accessing ssh over a network, which is considered pretty secure.
- hughesjj 2y ago
  ...why not just su then?
  - rpgwaiter 2y ago
    root would need a defined password, which opens up other security concerns
    - akira2501 2y ago
      Even if you allow passwordless su for users in the wheel group?
      - djbusby 2y ago
        Do what!?
      - bdd8f1df777b 2y ago
        That's extremely dangerous. Any software running as a wheel user can escalate privileges willy nilly.
        immibis 2y ago
        they can also access your ssh private keys
        rascul 2y ago
o11c 2y ago
I'm skeptical of the approach in the linked article, but: > I honestly don’t even know how dangerous that is because I’ve always been told to never allow it. You've fallen for the FUD. In reality, logging in directly as root over remote SSH is strictly more secure than logging in as user over remote SSH and then using `sudo`. If user@home uses ssh to root@server, then root@server is only compromised if user@home is compromised. If user@home uses ssh to user@server then sudo to root@server, then root@server is compromised if either user@home or user@server is compromised. In particular, it is fairly common for user@server to be running some other software such as daemons or cronjobs. Please don't give out free root escalation (and often lateral movement due to password reuse) to anyone who manages to infect through those! (This of course does not apply if sudo is used in whitelisted-commands-only mode and does not take either passwords or credentials fully accessible from the remote host)
- cycomanic 2y ago
  I'm not sure I agree with this argument. Sure you can say theoretically it's one less account that could be compromised, but in practice I see a bunch of caveats. 1. If we allow password based logins, there will be many orders of magnitude more login attempts to root than any other user. So if you have to allow password based logins, you pretty much never want to allow root login. 2. If we disallow password based logins, a user account would be as save as a root login, except again that the root account is the much more valuable target so will get much more attention. I also do see the relevance of cronjobs (root does run them as well) and naturally no user that has sudo privileges should be be running network exposed services. 3. In cases were admin rights have to be shared amongst multiple users, are you going to share the same key for all users (probably not a good idea) or give every user a separate key (making key management a bit of a nightmare, user management is much easier). 4. As you pointed out yourself sudo gives you much more fine-grained control over commands that can be run.
  - kchr 2y ago
    > 3. In cases were admin rights have to be shared amongst multiple users, are you going to share the same key for all users (probably not a good idea) or give every user a separate key (making key management a bit of a nightmare, user management is much easier). To solve the key management nightmare, short-lived SSH certificates can be used to map an identity to a shared user account. Hashicorp Vault is one option for issuing such certificates, but there are other alternatives as well. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication https://docs.redhat.com/en/documentation/red_hat_enterprise_....
fsniper 2y ago
The approach is comparing - Theoretical configuration errors, or theoretical vulnerabilities that may or may not be there with - Having a new daemon running (a new attack surface) which - may also have configuration errors, or vulnerabilities as such - and also removes a few layers of user based authorisation with a single root level This approach is somehow considered more secure. And in a rational way, and of course for any rational security perspective this can't be considered more secure, just different.
irusensei 2y ago
> How is logging into ssh (sshd) AS root more secure than using sudo? Article describes an additional SSH server listening on an Unix socket. The usual threat model about exposing root logins from the internet may not apply here.
joveian 2y ago
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.
- jeffhuys 2y ago
  Psst… privilege has no letter D

iroddis 2y ago

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. 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. To see all the amazing things that sudo can do, I’d really recommend the Sudo Mastery book.

yjftsjthsd-h 2y ago
SSH can do some of that with ForceCommand, though I agree that's not as flexible/precise.

hernantz 2y ago

This is a similar idea to run0 by Systemd: https://news.itsfoss.com/systemd-run0/ https://news.itsfoss.com/systemd-run0/

ape4 2y ago
And run0 isn't roll-your-own. Its audited and probably better than home grown.

mise_en_place 2y ago

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.

bogantech 2y ago
> if you need to be root, then login as root via console 1: This requires every user to have the root password, while sudo does not 2: If everyone just logs in as root there's no way to audit who actually logged in and did what.
- kchr 2y ago
  Additionally, you need to rotate and distribute the new root password to all root users when you want to remove access for someone.
- joveian 2y ago
  You can have multiple accounts with uid/gid 0 (and can set up smart card or u2f login too if you want).

xfitm3 2y ago

Fixing things that aren't broken. Changing things just because they can be changed. Sometimes boring and stagnant is good.

irusensei 2y ago
I wouldn’t go as far to say sudo is broken but have you considered why would people create things such as doas and run0 if sudo is good enough?

cycomanic 2y ago

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.

jethro_tell 2y ago
As far as I'm concerned, I use setuid/sudo for auditing. At this point, I don't really do multi-user/multi service boxes. Almost everything I have that's multi-tenant at this point is k8s and you can just use kubectl endpoint instead of ssh. But if you're allowed to log in, you're allowed to setuid to root. So for a k8s box, that's the platform infra team and access to the services on top is through the k8s permissions provider. For the platform infra teams, if you just need something like metrics and logs, that's already off box. If you need to trigger some job or workflow, you can use the pipeline. But when someone does log in and do root stuff, I want to have an audit log. I actually can't think of a single box I own where someone with a login doesn't also have root for everything. Obviously, I understand the services doing setuid thing, but in the case of services, you generally have systemd doing setuid to drop permissions instead of the other way around.
CaliforniaKarl 2y ago
> You can't even login at failsave console. Linux consoles (the ttys that appear over local display or remote-access KVM, or the ttyS* devices that appear over serial ports and IPMI SoL) do not use sudo or su. Those consoles use a program like `getty`, or a window-manager; all those programs are non-suid programs that are started as root. Your system should have a root password set, for logins via console.
- TacticalCoder 2y ago
  > Your system should have a root password set, for logins via console. TFA says that he's prefixing his password hash with '!', making login with a root password impossible (including at the console). Hence GP's question.

TacticalCoder 2y ago

100 000 times yes: I do something similar and I described that here on HN in a comment / comments in the past! The way I do is a bit different... 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). Then the only way to login is using SSH but, here's a little spin... with a Yubikey. 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). Then the sshd daemon is configured to only allow pub/priv key logins, no password logins. 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. That "ssh console" and its keyboard is on my desk, always withing reaching distance. 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. 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.

r4indeer 2y ago
Sounds like what you have is similar to the idea of a bastion host, even if not quite the same.

ChoHag 2y ago

[dead]

kelnos 2y ago

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 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: chgrp wheel /usr/bin/sudo chmod o-rwx /usr/bin/sudo 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. 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. 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.

alexey-salmin 2y ago
> 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.
- cqqxo4zV46cp 2y ago
  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.
- rascul 2y ago
  I've seen a wheel or sudo group often enough to think it's common.

gnuser 2y ago

Good stuff. Imagine this though: ssh as user access control using a multiuser system such as gnu/linux byw everyone should be using ed25519 or at least 2048+

RecycledEle 2y ago

It seems like a way for Fed.Gov to know everything we do on our computers. Kill it with fire.

RecycledEle 2y ago
They have some rule hidden somewhere that communications through sockets is less private than things in the terminal.

kccqzy 2y ago

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.

coretx 2y ago

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.

ketily 2y ago

This reminds me a little of plam 9 and inferno in treating local resources and network resources with a uniform protocol

tankenmate 2y ago

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).

joveian 2y ago
If you want traditional single user mode that drops you to a root shell even though your root account is locked add SYSTEMD_SULOGIN_FORCE=1 to the environment of rescue.service and emergency.service (systemctl edit rescue.service). Of course that exact solution isn't always a good idea depending on the situation but in general that situation can be delt with differently from normal access while running correctly.
- tankenmate 2y ago
  Ouch, that's a major security issue if configured that way. That's something I'll want to add to my hardening checks.

the8472 2y ago

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. To use SSH as a proper sudo replacement it'd need something closer to posix_spawn as an extension.

jwilk 2y ago
Bug report about the shell indirection: https://bugzilla.mindrot.org/show_bug.cgi?id=2283 https://bugzilla.mindrot.org/show_bug.cgi?id=2283

didntcheck 2y ago

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

YesThatTom2 2y ago

Usenix LISA (now called SRECon) had a paper about this technique in 2004: https://www.usenix.org/legacy/publications/library/proceedings/lisa04/tech/napier.html https://www.usenix.org/legacy/publications/library/proceedin... Those who ignore Usenix are doomed to repeat it … 20 years later.

prima-facie 2y ago

Isn't this what systemd run0 is now doing? 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. - https://mastodon.social/@pid_eins/112353324518585654 https://mastodon.social/@pid_eins/112353324518585654

bandie91 2y ago
why must systemd re-invent everything?

dheera 2y ago

> I changed the root password 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 alias sudo="su -c"

philkrylov 2y ago
Only with GNU su. A portable though limited replacement would be something like alias sudo="su root -c"