This just sounds like a bad idea, a solution in search of a problem. Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code. It’s also a very fundamental piece of the system that you want to always work, even (especially!) when other things get borked. The brief description of run0 already has too many potential points of failure.
I’ve actually ran into some of those problems. If you run sudo su --login someuser, it’s still part of your user’s process group and session. With run0 that would actually give you a shell equivalent to as if you logged in locally, and manage user units, all the PAM modules.
systemd-run can do a lot of stuff, basically anything you can possibly do in a systemd unit, which is basically every property you can set on a process. Processor affinity, memory limits, cgroups, capabilities, NUMA node binding, namespaces, everything.
I’m not sure I would adopt run0 as my goto since if D-Bus is hosed you’re really locked out and stuck. But it’s got its uses, and it’s just a symlink, it’s basically free so its existence is kBs of bloat at most. There’s always good ol su when you’re really stuck.
Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code.
Have to trust the code ? doas for OpenBSD was created because of issues with sudo.
Talking with deraadt and millert, however, I wasn’t quite alone. There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough.
I have 0 knowledge of these things, but I do know that people always comment that sudo is bloated, that nobody is truly using everything that sudo can do, only one basic command.
Nobody is using all of sudo’s features because those features are for different use cases. Case in point, LDAP support. At home, pretty much nobody uses it. But on the job, where there are tens to hundreds of machines that someone might need, and they’re all hooked into LDAP for centralized authentication management, it makes sense to have that built into sudo. Same with Kerberos support - at home, forget it, but in a campus environment where Kerberos (and possibly AFS) are part of the network, it makes sense.
sudo is a setuid binary, but it’s a fairly simple program
Some people would disagree to this.
The brief description of run0 already has too many potential points of failure.
If the “listener” is PID1, which will run the privileged command, in theory, it would be quite bullet proof (in a working system PID1 is always there). But since this is systemd, PID1 is much more than that and much more complex.
On the other hand spawning another daemon from PID1 to be the “listener” makes it, perhaps, even more complicated. You’d have to make sure the listener is always running and have some process supervisor there to watch if it exits… and maybe even a watchdog polling it to make sure it isn’t frozen.
So my conclusion is the same as yours:
a solution in search of a problem
We already have a working solution. Have a well written SUID program. I’ve been using doas for some years now. It’s simple enough that I trust it.
On a server, it allows you to track who initiates which root season session. It also greatly minimizes the attack surface from a security perspective to have admin privileged accounts unable to be remotely connected to.
Separate ssh keys for the user and the admin? Yeah, see point 2, admins should not be remotely accessible.
Really? How, exactly? Break the ssh key authentication? And wouldn’t that apply to all accounts equally?
Keys aren’t perfect security. They can easily be mishandled, sometimes getting published to GitHub, copied to USB drives which can easily be lost, etc.
Further, there have been attacks against SSH that let malicious actors connect remotely to any session, or take over existing sessions. By not allowing remote access on privileged accounts, you minimize risk.
Forcing a non privileged remote session to authenticate with a password establishes a second factor of security that is different from the first. This means a cracked password or a lost key is still not enough for a malicious actor to accomplish administrative privileges.
A key is something you have
A password is something you know
So, by not allowing remote privileged sessions, we’re forcing a malicious actor to take one more non-trivial step before arriving at their goals. A step that will likely be fairly obvious in logs on a monitored machine.
If I get into your non-privileged account I can set up a program that acts like sudo and I bet 99% of people will never notice they just gave their password away. And even if they do it’s too late anyway because I’ve just compromised root and locked everybody out and I’m in there shitting on the filesystems or whatever. Because root can do anything.
And if I can’t break into your non-privileged account then I can’t break into a privileged account either.
These artificial distinctions between “non-privileged” and “superuser” accounts need to stop. This is not good security, this is not zero trust. Either you don’t trust anybody and enforce explicit privilege escalation for specific things, or just accept that you’re using a “super” paradigm and once you’ve got access to that user all bets are off.
I strongly disagree with your premise. Separating authentication and privilege escalation adds layers of security that are non-trivial and greatly enhance resilience. Many attacks are detected and stopped at privilege escalation, because it happens locally before a user can stop or delete the flow of logs.
If I get into your non-privileged account I can set up a program that acts like sudo
No you cannot. A non privileged user doesn’t have the access necessary to run a program that can accomplish this.
And even if they do it’s too late anyway because I’ve just compromised root and locked everybody out and I’m in there shitting on the filesystems or whatever. Because root can do anything.
Once again, you didn’t privilege escalate, because once you have a foothold (authentication) you don’t have the necessary privileges, so you must perform reconnaissance to identify an exploitable vector to privilage escalate with. This can be any number of things, but it’s always noisy and slow, usually easy to detect in logs. There is a reason the most sophisticated attacks against well protected targets are “low and slow”.
And if I can’t break into your non-privileged account then I can’t break into a privileged account either.
You’re ignoring my points given regarding the risks of compromised keys. If there are no admin keys, there are no remote admin sessions.
These artificial distinctions between “non-privileged” and “superuser” accounts need to stop. This is not good security, this is not zero trust. Either you don’t trust anybody and enforce explicit privilege escalation for specific things, or just accept that you’re using a “super” paradigm and once you’ve got access to that user all bets are off.
Spoken like someone who has never red teamed or purple teamed. Even admin accounts are untrusted, given only privileges specific to their role, and closely monitored. That doesn’t mean they should have valid security measures thrown away.
This just sounds like a bad idea, a solution in search of a problem. Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code. It’s also a very fundamental piece of the system that you want to always work, even (especially!) when other things get borked. The brief description of run0 already has too many potential points of failure.
Sudo is actually fairly huge and complex. Alternatives like
reallyordoasorsuare absolutely tiny by comparison.The OP can make the same argument after replacing sudo with doas or su.
I’ve actually ran into some of those problems. If you run
sudo su --login someuser, it’s still part of your user’s process group and session. With run0 that would actually give you a shell equivalent to as if you logged in locally, and manage user units, all the PAM modules.systemd-run can do a lot of stuff, basically anything you can possibly do in a systemd unit, which is basically every property you can set on a process. Processor affinity, memory limits, cgroups, capabilities, NUMA node binding, namespaces, everything.
I’m not sure I would adopt run0 as my goto since if D-Bus is hosed you’re really locked out and stuck. But it’s got its uses, and it’s just a symlink, it’s basically free so its existence is kBs of bloat at most. There’s always good ol
suwhen you’re really stuck.Have to trust the code ? doas for OpenBSD was created because of issues with sudo.
I have 0 knowledge of these things, but I do know that people always comment that sudo is bloated, that nobody is truly using everything that sudo can do, only one basic command.
Nobody is using all of sudo’s features because those features are for different use cases. Case in point, LDAP support. At home, pretty much nobody uses it. But on the job, where there are tens to hundreds of machines that someone might need, and they’re all hooked into LDAP for centralized authentication management, it makes sense to have that built into sudo. Same with Kerberos support - at home, forget it, but in a campus environment where Kerberos (and possibly AFS) are part of the network, it makes sense.
Some people would disagree to this.
If the “listener” is PID1, which will run the privileged command, in theory, it would be quite bullet proof (in a working system PID1 is always there). But since this is systemd, PID1 is much more than that and much more complex. On the other hand spawning another daemon from PID1 to be the “listener” makes it, perhaps, even more complicated. You’d have to make sure the listener is always running and have some process supervisor there to watch if it exits… and maybe even a watchdog polling it to make sure it isn’t frozen.
So my conclusion is the same as yours:
We already have a working solution. Have a well written SUID program. I’ve been using doas for some years now. It’s simple enough that I trust it.
I’ve always wondered why we even bother with SUID commands. Why not just log in as root?
On a server, it allows you to track who initiates which root season session. It also greatly minimizes the attack surface from a security perspective to have admin privileged accounts unable to be remotely connected to.
Wouldn’t separate SSH keys achieve the same?
Really? How, exactly? Break the ssh key authentication? And wouldn’t that apply to all accounts equally?
Separate ssh keys for the user and the admin? Yeah, see point 2, admins should not be remotely accessible.
Keys aren’t perfect security. They can easily be mishandled, sometimes getting published to GitHub, copied to USB drives which can easily be lost, etc.
Further, there have been attacks against SSH that let malicious actors connect remotely to any session, or take over existing sessions. By not allowing remote access on privileged accounts, you minimize risk.
Forcing a non privileged remote session to authenticate with a password establishes a second factor of security that is different from the first. This means a cracked password or a lost key is still not enough for a malicious actor to accomplish administrative privileges.
A key is something you have
A password is something you know
So, by not allowing remote privileged sessions, we’re forcing a malicious actor to take one more non-trivial step before arriving at their goals. A step that will likely be fairly obvious in logs on a monitored machine.
If I get into your non-privileged account I can set up a program that acts like sudo and I bet 99% of people will never notice they just gave their password away. And even if they do it’s too late anyway because I’ve just compromised root and locked everybody out and I’m in there shitting on the filesystems or whatever. Because root can do anything.
And if I can’t break into your non-privileged account then I can’t break into a privileged account either.
These artificial distinctions between “non-privileged” and “superuser” accounts need to stop. This is not good security, this is not zero trust. Either you don’t trust anybody and enforce explicit privilege escalation for specific things, or just accept that you’re using a “super” paradigm and once you’ve got access to that user all bets are off.
I strongly disagree with your premise. Separating authentication and privilege escalation adds layers of security that are non-trivial and greatly enhance resilience. Many attacks are detected and stopped at privilege escalation, because it happens locally before a user can stop or delete the flow of logs.
No you cannot. A non privileged user doesn’t have the access necessary to run a program that can accomplish this.
Once again, you didn’t privilege escalate, because once you have a foothold (authentication) you don’t have the necessary privileges, so you must perform reconnaissance to identify an exploitable vector to privilage escalate with. This can be any number of things, but it’s always noisy and slow, usually easy to detect in logs. There is a reason the most sophisticated attacks against well protected targets are “low and slow”.
You’re ignoring my points given regarding the risks of compromised keys. If there are no admin keys, there are no remote admin sessions.
Spoken like someone who has never red teamed or purple teamed. Even admin accounts are untrusted, given only privileges specific to their role, and closely monitored. That doesn’t mean they should have valid security measures thrown away.
It would be a script called “sudo” somewhere in your PATH. You type sudo, you give it your password, done.
We used to do that a lot, in the 90s and early 2000s. We determined that that’s not a good idea. People even ran DEs under root.
I’m not saying to run everything as root but most of the reasons given for sudo are bull. This blog post makes a good job of debunking them.
Yeah. I keep one root tmux session open on my main PC for administrative tasks.