Which is the safest way to get root privileges: sudo, su or login?

Question

I would like to have the root account in safety even if my unprivileged user is compromised.

On Ubuntu you can only use sudo for "security reasons" by default. However I am not sure it is any safer than just using login on a text-mode console. There are too many things that can go wrong if an attacker can run code as my normal user. For example adding aliases, adding stuff to my PATH, setting LD_PRELOAD and X11 keyloggers just to mention a few. The only advantage I can see is the timeout so I never forget to log out.

I have the same doubts about su but it doesn't even have time limit. Some operations (especially IO redirection) are more convinient with su but security-wise this seems to be worse.

Login on a text-mode console seems to be the safest. Since it is started by init if an attacker can control PATH or LD_PRELOAD he is already root. The keypress events can't be intercepted by programs running on X. I don't know if programs running on X can intercept [ctrl]+[alt]+[f1] (and open a fullscreen window that looks like a console) or it is safe like [ctrl]+[alt]+[del] on Windows. Besides that the only problem I see is the lack of timeout.

So am I missing something? Why did the Ubuntu guys decide to only allow sudo? What can I do to improve the security of any of the methods?

What about SSH? Traditionally root can't log in through SSH. But using the above logic wouldn't this be the safest thing to do:

• allow root through SSH
• switch to text-mode
• log in as root
• ssh to the other machine
• log in as root?

Solution 1

Security is always about making trade-offs. Just like the proverbial server which is in a safe, unplugged, at the bottom of the ocean, root would be most secure if there were no way to access it at all.

LD_PRELOAD and PATH attacks like those you describe assume that there is an attacker with access to your account already, or at least to your dotfiles. Sudo doesn't protect against that very well at all — if they have your password, after all, no need to try tricking you for later... they can just use sudo now.

It's important to consider what Sudo was designed for originally: delegation of specific commands (like those to manage printers) to "sub-administrators" (perhaps grad students in a lab) without giving away root completely. Using sudo to do everything is the most common use I see now, but it's not necessarily the problem the program was meant to solve (hence the ridiculously complicated config file syntax).

But, sudo-for-unrestricted-root does address another security problem: manageability of root passwords. At many organizations, these tend to be passed around like candy, written on whiteboards, and left the same forever. That leaves a big vulnerability, since revoking or changing access becomes a big production number. Even keeping track of what machine has what password is a challenge — let alone tracking who knows which one.

Remember that most "cyber-crime" comes from within. With the root password situation described, it's hard to track down who did what — something sudo with remote logging deals with pretty well.

On your home system, I think it's really more a matter of the convenience of not having to remember two passwords. It's probable that many people were simply setting them to be the same — or worse, setting them to be the same initially and then letting them get out of sync, leaving the root password to rot.

Using passwords at all for SSH is dangerous, since password-sniffing trojaned ssh daemons are put into place in something like 90% of the real-world system compromises I've seen. It's much better to use SSH keys, and this can be a workable system for remote root access as well.

But the problem there is now you've moved from password management to key management, and ssh keys aren't really very manageable. There's no way of restricting copies, and if someone does make a copy, they have all the attempts they want to brute-force the passphrase. You can make policy saying that keys must be stored on removable devices and only mounted when needed, but there's no way of enforcing that — and now you've introduced the possibility of a removable device getting lost or stolen.

The highest security is going to come through one-time keys or time/counter-based cryptographic tokens. These can be done in software, but tamper-resistant hardware is even better. In the open source world, there's WiKiD, YubiKey, or LinOTP, and of course there's also the proprietary heavyweight RSA SecurID. If you're in a medium-to-large organization, or even a security-conscious small one, I highly recommend looking into one of these approaches for administrative access.

It's probably overkill for home, though, where you don't really have the management hassles — as long as you follow sensible security practices.

Solution 2

This is a very complex question. mattdm has already covered many points.

Between su and sudo, when you consider a single user, su is a little more secure in that an attacker who has found your password can't gain root privileges immediately. But all it takes is for the attacker to find a local root hole (relatively uncommon) or install a trojan and wait for you to run su.

Sudo has advantages even over a console login when there are multiple users. For example, if a system is configured with remote tamper-proof logs, you can always find out who last ran sudo (or whose account was compromised), but you don't know who typed the root password on the console.

I suspect Ubuntu's decision was partly in the interest of simplicity (only one password to remember) and partly in the interest of security and ease of credential distribution on shared machines (business or family).

Linux doesn't have a secure attention key or other secure user interface for authentication. As far as I know even OpenBSD doesn't have any. If you're that concerned about root access, you could disable root access from a running system altogether: if you want to be root, you would need to type something at the bootloader prompt. This is obviously not suitable for all use cases. (*BSD's securelevel works like this: at a high securelevel, there are things you can't do without rebooting, such as lowering the securelevel or accessing mounted raw devices directly.)

Restricting the ways one can become root is not always a gain for security. Remember the third member of the security triad: confidentiality, integrity, availability. Locking yourself out of your system can prevent you from responding to an incident.

Solution 3

The designers of the secured OpenWall GNU/*/Linux distro have also expressed critical opinions on su (for becoming root) and sudo. You might be interested in reading this thread:

...unfortunately both su and sudo are subtly but fundamentally flawed.

Apart from discussing the flaws of su and other things, Solar Designer also targets one specific reason to use su:

Yes, it used to be common sysadmin wisdom to "su root" rather than login as root. Those few who, when asked, could actually come up with a valid reason for this preference would refer to the better accountability achieved with this approach. Yes, this really is a good reason in favor of this approach. But it's also the only one. ...(read more)

In their distro, they have "completely got rid of SUID root programs in the default install" (i.e., including su; and they do not use capabilities for this):

For servers, I think people need to reconsider and, in most cases, disallow invocation of su and sudo by the users. There's no added security from the old "login as non-root, then su or sudo to root" sysadmin "wisdom", as compared to logging in as non-root and as root directly (two separate sessions). On the contrary, the latter approach is the only correct one, from a security standpoint:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(For accountability of multiple sysadmins, the system needs to support having multiple root-privileged accounts, like Owl does.)

(For desktops with X, this gets trickier.)

You also absolutely have to deal with...

BTW, they were to replace sulogin with msulogin to allow the setup with multiple root accounts: msulogin allows one to type in the user name also when going into the single user mode (and preserve the "accountability") (this info comes from this discussion in Russian).

Solution 4

You seem to be assuming that using sudo always preserves environment variables, but this is not always the case. Here is an excerpt from the sudo manpage:

There are two distinct ways to deal with environment variables. By default, the env_reset sudoers option is enabled. This causes commands to be executed with a minimal environment containing TERM, PATH, HOME, SHELL, LOGNAME, USER and USERNAME in addition to variables from the invoking process permitted by the env_check and env_keep sudoers options. There is effectively a whitelist for environment variables.

If, however, the env_reset option is disabled in sudoers, any variables not explicitly denied by the env_check and env_delete options are inherited from the invoking process. In this case, env_check and env_delete behave like a blacklist. Since it is not possible to blacklist all potentially dangerous environment variables, use of the default env_reset behavior is encouraged.

In all cases, environment variables with a value beginning with () are removed as they could be interpreted as bash functions. The list of environment variables that sudo allows or denies is contained in the output of sudo -V when run as root.

So if env_reset is enabled (the default), an attacker can't override your PATH or other environment variables (unless you specifically add them to a whitelist of variables which should be preserved).

Solution 5

The safest approach is ssh login using (at least) 2048 long key (with password login disabled) using a physical device to store the key.

View more solutions

Comments

[asoundmove]

In your ssh solution, do you mean that you want to ssh into the potentially comprimsed box from another box? 1/ If yes, then, to follow your train of thought, you must make sure that your other box is not compromised before you ssh from it. 2/ If no, then you have the same problem.

[stribika]

@asoundmove: There are 4 users with my ssh situation: root@hosta, root@hostb, stribika@hosta, stribika@hostb. Assuming an attacker can run arbitrary code as both stribikas (after all they are running flashplugin and whatnot) I still want safe root access. So both boxes can be partially compromised.

[Shadur]

"The safest way to get root privileges" is like asking for the safest way to use a chainsaw. It's inherently dangerous; what you want is risk mitigation.

[stribika]

I meant if the attacker can control my path he can make me run anything instead of the real /usr/bin/sudo. For example /tmp/sudo which prints Password: displays nothing when I type, sends what I typed to him, says the password is wrong, then execs the real sudo.

[Cedric]

Hmm, I guess in that case you could just run /usr/bin/sudo directly instead of relying on the shell to find it for you. But you're right, it's a problem I didn't think of.

[stribika]

@CedricStaub: As far as I can tell noone seems to think of this. I can give the full path but try this: alias /usr/bin/sudo="echo pwned" Besides that there are a ton of programs involved (X, xterm, the shell) any of which can steal the password. That's why I said there are far too many problems with switching safely.

[stribika]

Sure thing but root-to-root or unprivileged-to-unpriviliged then switch to root? (I'm actually using 4096 bit keys just to be on the safe side. Larger keys are not supported everywhere.)

[Šimon Tóth]

@stribika Well, both. If the machine is compromised you still don't loose your key. That prevents spreading (biggest problem with passwords).

[stribika]

I will accept this as the answer since it clears up a lot about what the Ubuntu developers were thinking when making sudo the default method. Remote logging also seems like a great idea and given that I'm using syslog-ng already it shouldn't be too hard to set up so all my computers log to all the others. I'm going to stick with my current practice of switching to text-mode and logging in from there for full root access. Delegating a subset of rights is certainly a good way to use sudo and one I have never considered.

[maaartinus]

Did you tried it? I did: bash: alias: `/usr/bin/sudo': invalid alias name

[Jörg W Mittag]

sudo is very similar to User Account Control in Windows Vista. Both are actually designed not to increase security, but actually to make it easier to decrease it in a controlled way. But because they make it easier to temporarily elevate your privileges in a low-friction manner, you don't need to run with elevated privileges for extended periods of time, thus increasing security. (This wasn't that big of a problem in Unix, but in Windows I remember running as Administrator for days on end, just because switching was so painful.)

[stribika]

@maaartinus: Interesting. It works in ZSH.

[Cedric]

It's a "feature" of zsh that it allows / in aliases if I remember correctly.

[psusi]

Password sniffing trojaned ssh daemons? If they can replace the ssh daemon, they already have root.

[mattdm]

@psusi: yes, on that system; in an environment where passwords are shared (by a directory service) between multiple systems, it's easy for a compromise to spread in this way. Even when it's a single system, it's a hassle to reprovision everyone's password after a reinstallation after the compromise has been detected.

[psusi]

If they can find your password, then they can find the root password just as easily if not easier. Also you can use sysrq-k as a secure attention sequence.

[mattdm]

See the comments on this question on SSH on serverfault.

[Shadur]

For a system that's basically meant to be a firewall and not much more this is fine, but if you're intending to run, as a random example, mysql/postgresql/bind/powerdns/apache and whatnot in a production system, you start running into problems, much as they describe with X. Essentially they've traded a lot of usability for a degree of security; it's up to the systems administrator to decide whether it's a fair tradeoff. Personally, I'll stick to Debian.

[Wildcard]

The potential difficulties of changing all your company's root passwords is also mentioned as the final item in the Ops Report Card, which is well worth reading.

[btshengsheng]

Linux has security attention keys, have a look at the kernel documentation

[Gilles 'SO- stop being evil']

@btshengsheng Linux can have a “secure attention key”, but since it can be configured out, you can't be confident that it's operating on any particular machine. It's also dependent on the keyboard layout, so it can be bypassed by reassigning one of the keys. It's called a “secure attention key”, but it doesn't quite fit the bill.

[another]

Your gold medal ;). +100