Operating systems

Security tools should be designed for security

When designing security tools, design them for security -- not to push some completely irrelevant ideological bias on your users.

For those who are not aware, there is a Unix command line security tool called su. Those of us who have been using Unix and Unix-like systems since before 2005 might think that anyone else using Unix and Unix-like systems must know about the su command, given its fundamental place in the Unix operating environment. It is, in fact, one of the key parts of an operating environment's design for security: a well-controlled, secure means of achieving authorized privilege escalation. The advent of Ubuntu Linux in late 2004, however, has upset some of that.

Ubuntu assumes that users should not be trusted with the su command, and should have to use sudo instead. While su allows the user to start a shell session with elevated privileges, sudo merely allows the user to execute a single command with elevated privileges. By default, Ubuntu disables su entirely -- or, more precisely, disables root logins, including by way of su -- and provides the user with sudo as its replacement. Because of the great popularity of Ubuntu Linux, and the fact that many Linux users these days have never used a different distribution, some of them may never have encountered su.

Some Ubuntu proponents believe this is a superior security model. They tend to offer arguments like that in TUX Magazine's sudo vs. su article. It makes a claim about the supposed dangers of su:

While this approach is a lot safer than just logging in as root, you still must remember to exit the administrator level with either exit or Control-D to get you back to your own user permissions. That means forgetting a step or just being lazy can be dangerous. A safer approach would be to require you to take action each time you want to run a command as root.

Even at first glance this argument seems pretty weak. It claims that sudo will protect you from yourself, by suggesting that you are too dumb, or forgetful, or unobservant, to avoid doing everything from within a root-privilege shell session you started via the su command. I do not know of anyone who has done this. People tend to do things that require root privileges, then exit out of that shell session when they are done. When all it takes is entering the exit command or using Ctrl-D, exiting a root shell session is about as easy as it could possibly be.

There is not even any reasonable convenience excuse for using sudo for all things root-level, since in an X session it is trivially easy to have side-by-side terminal emulator windows open, one with root privileges and the other with non-root privileges so you can use both at the same time if need be. By contrast, typing sudo before every single command when you know you will be entering quite a few commands that require root privileges can get fairly tedious.

At second glance, things only get worse, as explained in the basics of secure admin privilege use with Unix. In short, sudo is designed to provide a way to offer specific users very limited access to root privileges, so they can perform carefully selected tasks delegated to their particular authority on a system where they are not sysadmins, and should not have unfettered root access. Misusing it to provide system-wide root access in lieu of su can have unexpected consequences that might undermine the security benefits of the Unix privilege separation model.

Consider, for instance, the example of accessing a system remotely via SSH. If someone cracks the password for a standard user account that can be used to remotely access a given Unix-like system, the damage on a traditional setup can be limited somewhat by use of good system configuration:

  • If SSH is configured properly, the root user will not be directly available for remote login.
  • If an attacker manages to crack a less privileged user to gain access to the system, a separate password (the root password) is needed to escalate privileges via the su command.
  • If the user account is not a member of the wheel group and the system in question is running a sane su implementation, it will not have the ability to elevate privileges via the su command at all. By contrast, if you use SSH to remotely log in to the main user account on an Ubuntu system, the same password you just used will suffice for using sudo to perform tasks with root privileges.

There is, however, an unfortunate state of affairs that might be at least partially to blame for the way Ubuntu misuses sudo. There is a security risk in using su on most Linux distributions that does not apply to sudo, at least for some deployments of the OS. The only way to work around that shortcoming is to disable su and replace it in practice with sudo for root privilege access.

The problem is not with su per se. Instead, it is a problem with the GNU implementation of su. In the GNU Coreutils documentation at the gnu.org site, the su invocation page offers this gem:

23.6.1 Why GNU su does not support the 'wheel' group

(This section is by Richard Stallman.)

Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The “wheel group” feature would make this impossible, and thus cement the power of the rulers.

I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

Here we see Stallman imposing nonstandard behavior on his version of the su utility -- a security tool -- for ideological reasons that have nothing to do with security but, in fact, undermine the security the tool can provide. While sudo can always be limited to specific user accounts, the GNU version of su has specifically had the ability to limit its availability to specific users excluded. Incredibly, Stallman seems to want to make it as easy as possible for nonprivileged user accounts to escalate privileges, making the system more subject to brute force attacks and other unauthorized root access than usual. One might wonder if he secretly believes su should not require any passwords to escalate privileges.

By contrast, the BSD implementation only allows user accounts that are members of the wheel group to use su to escalate privileges. This is only right and proper, given that users who are authorized to perform sysadmin duties should be the only users to have administrative root access to the system. This is a security measure, and not a dastardly, unethical power grab as Stallman imagines in what frankly reads like a paranoid fantasy. "Power to the people" is a term that should stay in politics, and out of system administration. The owner of a system should have the ability to authorize or restrict root access as needed; these decisions are not Stallman's to make by eliminating important, basic functionality from security tools at his arbitrary whim.

On a single-user desktop computer, this intentional crippling of the su tool may not be a big deal most of the time, so long as remote shell access is tightly controlled so that someone out there on the Internet cannot just gain shell access and escalate privileges through a brute force attack. On systems running many server processes such as httpd that may be operating under the auspices of a special user account, the dangers of allowing all user accounts to use su become more immediate and worrisome.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

35 comments
ernied
ernied

*sigh* *This* is what sudo is intended to avoid: Here's a trivial way that a hacker or virus programmer could easily do an end-run around Unix privilege separation: $ cd ~ $ echo "echo I just did something as root" > ls $ sed -i 's/PATH.*/PATH=~/' .bash_profile $ logout [log back in] $ su Password: # ls I just did something as root # Of course, you *could* use `su -` all the time, but you just have to be lazy that one time... The entire point of sudo is to force the user to only run the bare minimum of programs as root. Just like secure programming requires that privilege escalation should be done infrequently (if at all) and as briefly as possible. Sudo also allows an administrator (computers can be used by more than one person, didn't you know?) to control which commands are allowed to be run as root, and which users are allowed to do so.

AVery1
AVery1

Well I do not normally respond to articles but this one has me concerned. su is not a SECURITY tool. It is a utility to allow the changing of identities. The command is Switch User and the default user is root. su is available in Debian and Ubuntu but does not have a default of root. To control who is permitted to become root the group wheel is used in BSD implementations. Therefore a user must log in and if they are in the wheel group then they are permitted to switch to the root identity. sudo further extends this permissions thing by not having a root password and thus only those persons who are in the admin group or who have been granted limited permissions using the sudoers file are permitted to run system commands and utilities. This is overkill on a desktop system but in a server it is important to control who can do what. As you pointed out an unhappy sysadmin can change the root password and lock out everyone. However using sudo that person would have to change the password for everyone in the group. A sysadmin will keep his/her password to them selves however the root password becomes a none issue when it is the same on every system at the location and tends to be passed around by the responsible people. Those same people do not share their account passwords with the rest of the IT staff. So IMHO su is NOT a security tool, it is a convenience for sysadmins. sudo is a tool to provide a granular control mechanism for system administrator programs and utilities.

Jaqui
Jaqui

is a fringe radical. he's ok with that. :) no need for me to mention my opinion of the article for you. You know I agree with you on it. :)

bblackmoor
bblackmoor

There is nothing wrong with sudo. sudo is a useful and secure tool for privilege escalation. The problem is that Ubuntu makes defangs sudo and makes it pointless, which is just as bad if not worse than Stallman imposing his vision of utopia on su.

kamprianism
kamprianism

is what I use when I need to do some administrative work and don't want to write sudo all the time. So I find sudo as implemented by Ubuntu a security problem instead of a solution, since the user's password alone can provide root access.

lastchip
lastchip

A top quality (as always) article from you Chad, but I don't remember ever seeing a group wheel, so I looked in /etc/group (Debian system) and sure enough, it doesn't appear. Am I missing something, or is wheel something that is built into the kernel, that is not a normal group? Or is it, as Debian is the mother of Ubuntu, it doesn't use that group either? Certainly, I use su all the time in Debian, so it's definitely implemented. But how?

seanferd
seanferd

Thank you. You have killed several mysteries with one stone.

tbmay
tbmay

It is a quick way to get a working desktop up when you don't need much security. I don't put it on servers, at least when it's my choice to make. I do have a few clients who insist. They know I'm not crazy about it but I do help them with their projects. All that said, it was a good article and I too don't like sudo on systems that are meant to be secure and safe.

ignatp
ignatp

This article's main point is completely rediculous. Using pam you can limit su to wheel by putting: auth required pam_wheel.so use_uid in pam.d/su. If you're not using pam on linux then you have bigger problems to worry about than non-wheel users using su.

Sterling chip Camden
Sterling chip Camden

So Ubuntu tries the old "two wrongs make a right" approach to security. I've been using systems with superuser access since 1978 (DG AOS had the concept, too) and (touch wood) have yet to experience a break-in through that vector. Unix's default behavior of changing the prompt for root access helps to remind you that you should press Ctrl+D at your earliest convenience. I also change the text color so it really stands out. Using only sudo, you can't do anything that requires context to be maintained between commands, nor can you access shell aliases for either the root user or the logged in user. With su you get a shell context, and the aliases for root.

apotheon
apotheon

The article addresses using sudo as a complete, generic su replacement -- not using sudo as it was intended, as a way to provide limited administrative capabilities to a particular user account. You've addressed the matter of how using sudo properly can be useful for security, and not the topic discussed in the article. (edit: typo)

Jaqui
Jaqui

with end user password for ALL system admin sudo is most definitely less secure. and that is the Cannonical sin for all variants of their distro.

apotheon
apotheon

> su is not a SECURITY tool. It is a utility to allow the changing of identities. Anything that allows one to switch user accounts -- that allows one to alter one's own privileges on the system -- is either a security tool or a security circumvention tool. Because of the way su is designed to prevent arbitrary abuse (except on misconfigured systems, but that's another story entirely), it's a security tool by design. In fact, it's pretty difficult to get the system to let you su from one unprivileged account to another, regardless of whether either account is in the wheel group. This tool is in practice a privilege escalation tool for the common case. The second most likely use case is changing one's credentials from root to some unprivileged user for administrative purposes -- also essentially a security use of the utility. You haven't explained how something that allows you to swap system privileges is necessarily not a security tool. Would you consider sudo (which does the same thing, just in a very different way) to be a security tool? > The command is Switch User and the default user is root. Actually, it's "substitute user" -- but who's counting? > su is available in Debian and Ubuntu but does not have a default of root. Have you tried using su when logged in with a nonprivileged account to assume the credentials of another nonprivileged account lately? > So IMHO su is NOT a security tool, it is a convenience for sysadmins. Convenience when it comes to operating in a secure manner makes something a security tool -- because the alternative is less convenience for doing things in a secure manner, which leads to doing things in a way that violates good security sense. Interface design is security design, after all. What's your idea of a security tool, anyway? I'd bet real money that whatever example you could present could be disallowed using a similar means of making up some nitpicky disqualifier. "A firewall? No, that's not a security tool. It's just a tool that provides a granular control mechanism for filtering network packets." Maybe this is just a misguided attempt to justify the lunacy of RMS. (edit: typo)

apotheon
apotheon

The fact that sudo is being abused -- rather than properly used -- in Ubuntu was sorta the point of the article explaining how Ubuntu abuses it.

apotheon
apotheon

Debian doesn't have the wheel group by default. You have to add it, then configure pam to use it to work around the GNU su limitation. It's kind of a dirty hack, but it works if you want to emulate proper su behavior.

apotheon
apotheon

I am Ozymandias, Slayer of Mysteries. Look on my works, ye mighty, and, err, be unimpressed. Hah!

Neon Samurai
Neon Samurai

I was pleasantly surprised to see a console based install wizard when I look at it. I wouldn't be using the workstation builds but the server default settings may be more sane (though, why youd us Ubuntu server instead of Debian.. I don't know).

ernied
ernied

The entire argument against sudo-instead-of-su assumes the following: 1. You're using Ubuntu for a task other than a workstation, or your workstation has remote access via ssh enabled through the (separate, usually) firewall (really, who has their workstation connected directly to the internet?). 2. That brute-forcing the password is a worthwhile endeavour for an attacker. 3. That you can't mitigate the brute-forcing of a user's password. My argument is that unless the *user's* password is brute-forced, sudo is more secure than su. The only time I've ever seen a user's password get brute-forced is when the user's password is spectacularly stupid, like when the u/p is mike/mike2010. The only time random internet hackers ever make a concerted effort against a password is when they know the username, and more importantly, that they know that username leads to superuser access; ie: root. Then, the author of this article makes the assumption that sudo is only for the weak-minded fools who are too lazy or distracted or otherwise forget to hit Ctrl-D when they're finished doing whatever they need to do as root. This however, basically describes 95% of system administrators. Which is *exactly* why sudo was created in the first place. And molly-guard, for that matter. Humans make mistakes. Humans who are good at their jobs and professional about it make somewhat fewer mistakes. But stupidity like using the 'ls' command as root can be pretty much expected. The fact of the matter is that by removing the root account, and forcing the end-user to type in their password for the things that require superuser access, you're actually increasing the security of the system. Especially on workstations that are protected by NAT routers, which is pretty much the target market for Ubuntu. If Ubuntu is failing at security somehow by doing this, it's only because they allow stupid passwords (well, they almost do - you can't use your username as your password, but mike/mike2010 is still possible) and they don't have something like fail2ban installed by default. These two features effectively snuff out any hope that attackers might have to brute-forcing passwords. If they can manage to guess the username, that is. Most brute-force password attacks are really lame and are only intended to find the easiest possible passwords. Hackers generally don't spend a lot of time on these kinds of attacks because other vulnerabilities are much faster and easier to take advantage of. Like say, the trivial virus/worm attack I just mentioned.

lastchip
lastchip

I'll investigate further.

Juanita Marquez
Juanita Marquez

Funny, I didn't know you cavorted around the house in purple and gold tights... / < comicbookgeeksnicker >

tbmay
tbmay

It's what the clients I was referring to use. I agree you with. Lenny (current stable) is a much better choice. Or RHEL/CentOS. But I can't change their minds because it's what they're comfortable with. Most of my clients do defer to my choices though.

apotheon
apotheon

The only reason to use Ubuntu server instead of Debian, as far as I can tell, is branding.

martian
martian

An admin terminal session is possible via the command "sudo bash". I guess that would be about the same.

shryko
shryko

In ubuntu, they even make mention of it on many of the common help guides. It's the way I generally go about doing sys admin stuff on my laptop.

apotheon
apotheon

Neon Samurai did a pretty good job of responding to your points, so I'll let his statements stand. As for me "looking like a pedantic noob," I'd appreciate it if you'd try to stick to attacking my ideas rather than attacking me personally. I thought you were just wrong at first, but I'm beginning to get the impression you also aren't a very nice person.

Neon Samurai
Neon Samurai

"Why would you want to deploy Ubuntu on a server" Canonical also produces Ubuntu Server Edition which does not apear to have X. Personally, I'd go with debian but if one wants Ubuntu Server, it exists. "why run an SSH daemon on a workstation/laptop at all?" - remote administration - remote software use (both cli and gui) - transfer of files to the workstation - tunneling of unencrypted protocols - provide secure network shares (eg. sshfs) - provide secondary display/input when working with display drivers (I wouldn't build a workstation without ssh after that one) (yes, at home, my workstation is my vpn server so "provide vpn" also applies) "Also, if the end user has a stupid password, what's stopping said user from setting the root password to be the same as the user password? " That doesn't mean we should promote insecure practice; especially when the better practice is just as easy. Someone's only going to rob the bank anyway so we should just leave all the bags of money on the front steps; it's easier that way after all. What really scares me is the Linux Journal article "make sudo behave like Ubuntu on other distributions". I expect it to shortly be followed up by an article on how to make mammals retract there legs and return to the water or some similar self induced devolution. "If they really cared to get root access, local (offline, as you say) brute forcing of the password is very fast through 'su', which *has* no tarpitting or lock-out ability." If someone is that serious about getting root access, are we already not dealing with a targeted attack? Would they have gotten passwd/shadow files if the user account they breached didn't have a weak password? If they are cracking the passwords offline, wouldn't they use a specific cracking tool like John rather than reconstruct a duplicate lab system so they can run sucrack? "By the way, I know the pedantic difference between the word "hacker" and "cracker". The people who cared about the original abuse of the term some 20 years ago have ceased to care, and so should you. Unless you want to keep looking like a pedantic noob." Talks at every hacker related conference each year since those "20 years ago" would seem to indicate that people do still care about the use of the title and correcting the public misconception of it. I thought the single line pointing out your incorrect use was a rather civil inclusion. Given your admitted knowing the difference, would it have been that hard to use the correct term "cracker" where what you meant was a cracker; or ideally "criminal" when what you meant was criminal intent?

ernied
ernied

Anyway, you seem to want to assume that nobody uses Ubuntu outside of workstation deployments inside a corporate network, which I find an unlikely restriction. Why would you want to deploy Ubuntu on a server, when really it's just a pretty version of Debian? Who needs X on a server? Running X is a security vulnerability in itself, nevermind a massive resource hog. That aside, why run an SSH daemon on a workstation/laptop at all? In your example of a corporate VPN through SSH, is the *laptop* the VPN server? No, that's brain damaged. Also, if the end user has a stupid password, what's stopping said user from setting the root password to be the same as the user password? A systems administrator who also shut off the SSH daemon (if it was ever running by default to begin with) and any other servers on the laptop. Who then ran nmap against the laptop to make sure. And who probably set the password to something harder and gave the user a lecture about what happens to people who use bad passwords. The fact of the matter is, that should an attacker ever get shell access of any kind (even as user "nobody"), it's pretty much game over. If they really cared to get root access, local (offline, as you say) brute forcing of the password is very fast through 'su', which *has* no tarpitting or lock-out ability. These days, attackers are mostly interested in nothing more than a CPU on an IP address, from which they run highly profitable phishing and spam attacks. If they're interested in corporate espionage, then it's all about attacking the internal network from that one vulnerable laptop (at any level of access). If there were any data on the laptop worth getting, it wouldn't be saved with read-only permissions for the "root" user, it would all be owned by the primary user. Which the attacker already has the password for, apparently. So really, the difference between su and sudo is all about what access that user has to his own system. And whether or not he totally screws up the configuration on a regular basis. By the way, I know the pedantic difference between the word "hacker" and "cracker". The people who cared about the original abuse of the term some 20 years ago have ceased to care, and so should you. Unless you want to keep looking like a pedantic noob.

apotheon
apotheon

> The entire argument against sudo-instead-of-su assumes the following: Nope. I'll elaborate: > 1. You're using Ubuntu for a task other than a workstation, or your workstation has remote access via ssh enabled through the (separate, usually) firewall (really, who has their workstation connected directly to the internet?). What if it's a laptop "workstation", and you take it with you when you travel for work? What if SSH is used for your business VPN? What if someone inside the corporate network decides to access your computer for some nefarious purpose -- and use your computer to some unseemly end, using your account, leaving you holding the bag when someone notices something bad has happened? The possibilities are endless. Anyway, you seem to want to assume that nobody uses Ubuntu outside of workstation deployments inside a corporate network, which I find an unlikely restriction. > 2. That brute-forcing the password is a worthwhile endeavour for an attacker. . . . or that some other means of gaining the password is worthwhile, or that the user actually uses the same password for online purposes, or that the attacker can gain access via some vulnerability that bypasses the password but gives the attacker access to the passwd utility, or any of a number of other possibilities. > 3. That you can't mitigate the brute-forcing of a user's password. This assumption of yours kinda loses its relevance in light of the above. > My argument is that unless the *user's* password is brute-forced, sudo is more secure than su. I still don't see how sudo is more secure as a generic replacement for su. Sure, it's a more secure way to grant root privileges to someone who only needs to perform specific, limited tasks with root privileges, if it's used correctly. I see no reason to think it is "more secure" as a straight-up replacement for su. > The only time I've ever seen a user's password get brute-forced is when the user's password is spectacularly stupid, like when the u/p is mike/mike2010. That's actually pretty common. > The only time random internet hackers ever make a concerted effort against a password is when they know the username, and more importantly, that they know that username leads to superuser access; ie: root. It's actually quite common for usernames to be sent as part of normal traffic for a number of networking protocols. It is also often quite easy to determine that a particular system is running Ubuntu, since OSes tend to identify themselves by default in network traffic -- and if it's Ubuntu, you can be pretty sure the user account in use has direct sudo access to everything on the system. > Then, the author of this article makes the assumption that sudo is only for the weak-minded fools who are too lazy or distracted or otherwise forget to hit Ctrl-D when they're finished doing whatever they need to do as root. This however, basically describes 95% of system administrators. Which is *exactly* why sudo was created in the first place. Wrong. It was created to provide a way to grant granular, limited administrative privileges to those who need them -- such as when someone needs to be able to update the locate database for the whole system, but should not be allowed to do things like create new user accounts. > The fact of the matter is that by removing the root account, and forcing the end-user to type in their password for the things that require superuser access, you're actually increasing the security of the system. Yeah, that doesn't make any sense. You're basically saying that you increase the security of the system by requiring people to use the same password for accessing the system remotely as they use to execute commands with root privileges. Using separate passwords for these operations improves security. > Especially on workstations that are protected by NAT routers, which is pretty much the target market for Ubuntu. Actually, in practice, the target market appears to be people who don't own routers. They just hook up directly to the cable modem. > These two features effectively snuff out any hope that attackers might have to brute-forcing passwords. You clearly aren't familiar with offline brute force cracking if you think any reasonable possibility of brute force cracking a password is eliminated by disallowing the simplest passwords and limiting login attempts. > Most brute-force password attacks are really lame and are only intended to find the easiest possible passwords. . . . which is, unfortunately, most passwords. That's why they're the easiest; because they're common. If nobody used them, they wouldn't be easy to crack for any reasonable brute force methods. > Hackers generally don't spend a lot of time on these kinds of attacks because other vulnerabilities are much faster and easier to take advantage of. Like say, the trivial virus/worm attack I just mentioned. 1. You're misusing the term "hacker". 2. You should not ignore a blatant and obvious security vulnerability just because another vulnerability is more blatant and obvious. 3. Viruses and worms generally require direct user help to execute on non-Microsoft OSes. 4. Your "worm" attack requires as much access to the system as unauthorized use of sudo requires on Ubuntu, and it does less. That's not much of an argument for the superiority of sudo for security purposes. 5. You're ignoring the fact that sudo is much more susceptible to potential security vulnerabilities than su itself. By the way, your ls "worm" wouldn't work on my FreeBSD laptop, because the path is changed to that of the target user ID when using su to elevate privileges. The vulnerability you would exploit isn't a problem with su -- it's a problem with GNU su. Just thought I'd mention.

apotheon
apotheon

I'm considering writing an article that covers this subject. I'm not sure yet whether I will, but if you don't get around to finding the necessary information for that on your own very quickly, I may get to it first.

apotheon
apotheon

I'm thinking about an action figure product line.

apotheon
apotheon

Why do you think it should be bash instead of sh?

Editor's Picks