Enterprise Software

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.


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.

Editor's Picks