5 ms·

Never login as root… even over secured links!

by edf13 4y ago

e12e 4y ago
Indeed, "root" is not a person - only persons should have authorization (to log in, to elevate via su/sudo). Ed: although in this case the binding between a system user and a person happens at the tailscale level.
- megous 4y ago
  "bob" UNIX account is not a person either. If you ssh in, no matter to what account, your key ID is logged and that's what matters. Anything can happen afterwards, unless you have a really tight grip on your system, since local privilege escallations are not that hard or uncommon.
lfmunoz4 4y ago
alerighi 4y ago
Why? To me it doesn’t make sense not to do so. What kind of security gives you logging it as non root user and then using sudo (maybe even without a password) to become root? Root makes everything more easier, for example to copy a file on a server with scp if you don’t have root login you first has to copy it to /tmp and the copy it in the right directory by logging in as normal user and elevating with su/sudo. Also you have to remember which username was chosen when the server was installed, was it user, admin, or pi, or some default? I get not using root for everyday usage on a desktop, but for a server having a non root user is not that useful. Of course you have to know what you are doing, but sudo doesn’t protect you from stupid mistakes anyway (especially if configured with NOPASSWD as I always see doing because having to continuously type the password is annoying and password tends to be forgotten)
- kevin_nisbet 4y ago
  It probably depends a bit on your security posture and how you manage the server. The recommendation for avoiding root tends to be central to the idea of least privilege. By default, grant/allow the least privileges necessary, helps eliminate alot of security surface area, while also being a layer of protection against mistakes. It's easy to be careless with a superuser account, and have a bad day. And this is naturally in conflict with being productive. As you mentioned, it's easier to be productive if you can just do all of the things all of the time. And operating in environments where a mistake may not be that devastating, or compromise or vulnerability this might be a reasonable tradeoff. But I've worked in environments where this is too risky. For example: 1. Engineer accidentally pastes the wrong buffer into a terminal. They had accidentally copied some other piece of text. 2. The text happens to contain \nhostname set\n. 3. The terminal as it's spitting out errors, does see a valid command, to change the hostname. 4. That particular system was an HA system, and the process monitor in use, grepping the running processes for the command + args, of which hostname was an argument. And decided the process was no longer running. 5. The cluster seeing the failure, decides to boot another process. But at this time in history, that process was could only handle a single instance. Both instances now decided to conflict with each other. 6. Some part I don't remember about the failover site. 7. A million cell phones can no longer get an IP address. So it's a question of tradeoffs, but is a generally recommended practice to not login directly to root, and operate with less privileges when not required. And then escalate if granted / required.
  - structural 4y ago
    This is spot on. One interesting approach I've seen before is that all commands executed as the superuser must be written in file, and the only command accessible via sudo is "please_save_to_audit_log_then_run_it_in_sandboxed_env <file>". For particularly high-risk situations, there might be a second person reading your script before running an approval command that actually lets the script run. Things don't move quickly, but the number of mistakes via typo is certainly reduced.
dx034 4y ago
I've always heard that and adhered to that, but what's the advantage of me logging in with a user account to then use sudo for every command? It's not like I could break less than being logged in as root.
- edf13 4y ago
  Lots of reasons… Tracking actions, fine grained policy controls, sharing a root password amongst multiple people, and then there is the risk of accidentally running a cmd as root when you thought you were in your home shell!
  - dx034 4y ago
    Confusing the server I'm on will always cause issues, not matter if I have to sudo for root. I get the other points, but most servers I encountered don't have these fine grained controls because doing manual work on them only happens for debugging or fixing issues. And the password doesn't need to be shared with sth like Tailscale. Tracking actions is a good part though, I wonder if you can still track which tailscale user was responsible for that root login.
deleted 4y ago
[deleted]
8organicbits 4y ago
I think in this context, I'd worry about attributing any actions taken on the root account back to a named user. I suppose tailscale keeps an auth log (anyone know details?) so you likely could determine "root"="alice" by looking across different log files. Attributing privileged commands to an employee is critical for security. In other contexts you want to avoid shared root accounts, as you'd want to block access for former employees, but you don't want to rotate credentials every time. SSO for tailscale makes that easier.

Never login as root… even over secured links!

by edf13 4y ago

Never login as root… even over secured links!

e12e 4y ago

Indeed, "root" is not a person - only persons should have authorization (to log in, to elevate via su/sudo). Ed: although in this case the binding between a system user and a person happens at the tailscale level.

megous 4y ago
"bob" UNIX account is not a person either. If you ssh in, no matter to what account, your key ID is logged and that's what matters. Anything can happen afterwards, unless you have a really tight grip on your system, since local privilege escallations are not that hard or uncommon.

lfmunoz4 4y ago

alerighi 4y ago

Why? To me it doesn’t make sense not to do so. What kind of security gives you logging it as non root user and then using sudo (maybe even without a password) to become root? Root makes everything more easier, for example to copy a file on a server with scp if you don’t have root login you first has to copy it to /tmp and the copy it in the right directory by logging in as normal user and elevating with su/sudo. Also you have to remember which username was chosen when the server was installed, was it user, admin, or pi, or some default? I get not using root for everyday usage on a desktop, but for a server having a non root user is not that useful. Of course you have to know what you are doing, but sudo doesn’t protect you from stupid mistakes anyway (especially if configured with NOPASSWD as I always see doing because having to continuously type the password is annoying and password tends to be forgotten)

kevin_nisbet 4y ago
It probably depends a bit on your security posture and how you manage the server. The recommendation for avoiding root tends to be central to the idea of least privilege. By default, grant/allow the least privileges necessary, helps eliminate alot of security surface area, while also being a layer of protection against mistakes. It's easy to be careless with a superuser account, and have a bad day. And this is naturally in conflict with being productive. As you mentioned, it's easier to be productive if you can just do all of the things all of the time. And operating in environments where a mistake may not be that devastating, or compromise or vulnerability this might be a reasonable tradeoff. But I've worked in environments where this is too risky. For example: 1. Engineer accidentally pastes the wrong buffer into a terminal. They had accidentally copied some other piece of text. 2. The text happens to contain \nhostname set\n. 3. The terminal as it's spitting out errors, does see a valid command, to change the hostname. 4. That particular system was an HA system, and the process monitor in use, grepping the running processes for the command + args, of which hostname was an argument. And decided the process was no longer running. 5. The cluster seeing the failure, decides to boot another process. But at this time in history, that process was could only handle a single instance. Both instances now decided to conflict with each other. 6. Some part I don't remember about the failover site. 7. A million cell phones can no longer get an IP address. So it's a question of tradeoffs, but is a generally recommended practice to not login directly to root, and operate with less privileges when not required. And then escalate if granted / required.
- structural 4y ago
  This is spot on. One interesting approach I've seen before is that all commands executed as the superuser must be written in file, and the only command accessible via sudo is "please_save_to_audit_log_then_run_it_in_sandboxed_env <file>". For particularly high-risk situations, there might be a second person reading your script before running an approval command that actually lets the script run. Things don't move quickly, but the number of mistakes via typo is certainly reduced.

dx034 4y ago

I've always heard that and adhered to that, but what's the advantage of me logging in with a user account to then use sudo for every command? It's not like I could break less than being logged in as root.

edf13 4y ago
Lots of reasons… Tracking actions, fine grained policy controls, sharing a root password amongst multiple people, and then there is the risk of accidentally running a cmd as root when you thought you were in your home shell!
- dx034 4y ago
  Confusing the server I'm on will always cause issues, not matter if I have to sudo for root. I get the other points, but most servers I encountered don't have these fine grained controls because doing manual work on them only happens for debugging or fixing issues. And the password doesn't need to be shared with sth like Tailscale. Tracking actions is a good part though, I wonder if you can still track which tailscale user was responsible for that root login.

deleted 4y ago

[deleted]

8organicbits 4y ago

I think in this context, I'd worry about attributing any actions taken on the root account back to a named user. I suppose tailscale keeps an auth log (anyone know details?) so you likely could determine "root"="alice" by looking across different log files. Attributing privileged commands to an employee is critical for security. In other contexts you want to avoid shared root accounts, as you'd want to block access for former employees, but you don't want to rotate credentials every time. SSO for tailscale makes that easier.