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 removedting 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 removedting 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.
That’s called ‘privilege escalation’, and replacing system level calls with user level calls is closely watched for and guarded against with many different security measures including SELinux.
You’ve already outed yourself multiple times in this thread as someone who doesn’t understand how security in the real world works. Take the L and try to learn from this. It’s okay not to understand something. But it’s very important to recognize when that happens and not claim to understand better than someone else.
It’s not privilege escalation because it doesn’t subvert the correct authentication mechanism, it leverages it. This particular technique is called UI input capture. It’s a script that shows a password prompt then uses your password to do things as root. Nothing untowards would be detected. The main defense is to always run commands with full path – which nobody does.
Separating the process of reaching root in two steps does nothing to improve security, it actually increases complexity and subverts security. If the system is set up to SSH as root you either have a good key or you don’t. If you force people to SSH as individual users and then use a complex mechanism to reach root you create opportunity for a hundred more attack methods, and add a false sense of security.
Input capture btw is not the only method. Sudo has a lot of them. Another very common one is leveraging the password cache timeout.
You’ve already outed yourself
How about we skip the dick measuring contest and we stick to the discussion at hand.
sudo and friends allow you to gain root access while not enabling the root account. If the root account has no credentials then nobody is guessing your password and logging in as an admin.
On a multi-user system it allows for multiple admins without sharing a password. It also allows providing admin access for “some” things but not others.
If the root account has no credentials then nobody is guessing your password and logging in as an admin.
They just need to log in as you and trick you into entering your password in a seemingly legit prompt.
On a multi-user system it allows for multiple admins without sharing a password.
Multiple distinct ssh keys do the same. As long as everybody ends up doing things as the same user it’s all moot anyway.
It also allows providing admin access for “some” things but not others.
Can I provide selective access to just some files? Just some network interfaces? Just some ports? Just some parts of RAM or CPU? Without being able to change those limits?
The point I’m trying to make is that having just one “super” account for everything is a very poor idea. A lot of work has gone into filtering access to the root account and very little into getting rid of the root account. Ideally nothing should run as root, it should run as individual accounts with varying levels of access on a need-to-have basis.
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 removedting 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.
That’s called ‘privilege escalation’, and replacing system level calls with user level calls is closely watched for and guarded against with many different security measures including SELinux.
You’ve already outed yourself multiple times in this thread as someone who doesn’t understand how security in the real world works. Take the L and try to learn from this. It’s okay not to understand something. But it’s very important to recognize when that happens and not claim to understand better than someone else.
It’s not privilege escalation because it doesn’t subvert the correct authentication mechanism, it leverages it. This particular technique is called UI input capture. It’s a script that shows a password prompt then uses your password to do things as root. Nothing untowards would be detected. The main defense is to always run commands with full path – which nobody does.
Separating the process of reaching root in two steps does nothing to improve security, it actually increases complexity and subverts security. If the system is set up to SSH as root you either have a good key or you don’t. If you force people to SSH as individual users and then use a complex mechanism to reach root you create opportunity for a hundred more attack methods, and add a false sense of security.
Input capture btw is not the only method. Sudo has a lot of them. Another very common one is leveraging the password cache timeout.
How about we skip the dick measuring contest and we stick to the discussion at hand.
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.
sudo and friends allow you to gain root access while not enabling the root account. If the root account has no credentials then nobody is guessing your password and logging in as an admin.
On a multi-user system it allows for multiple admins without sharing a password. It also allows providing admin access for “some” things but not others.
They just need to log in as you and trick you into entering your password in a seemingly legit prompt.
Multiple distinct ssh keys do the same. As long as everybody ends up doing things as the same user it’s all moot anyway.
Can I provide selective access to just some files? Just some network interfaces? Just some ports? Just some parts of RAM or CPU? Without being able to change those limits?
So just login as root to your system then. You’ll be fine.
The point I’m trying to make is that having just one “super” account for everything is a very poor idea. A lot of work has gone into filtering access to the root account and very little into getting rid of the root account. Ideally nothing should run as root, it should run as individual accounts with varying levels of access on a need-to-have basis.
"That’s* what you meant when you said this???
Yeah. I keep one root tmux session open on my main PC for administrative tasks.