Operating systems

The basics of secure admin privilege use with Unix

Sometimes, it's worthwhile to get back to basics. Read about the basics of secure administrative privilege use on Unix-like systems.

Some of my readers may find this a very basic article, presenting information that they already know like the backs of their hands. The frequency with which I see people -- and even entire OS development teams -- violating basic, common security sense with regard to secure administrative privilege use on Unix-like systems prompts me to explain those basics here, though. That does not necessarily mean they are stupid, of course; some of the "basics" are not at all obvious.

The root account is probably the best place to start.

Using the root account

The standard administrative superuser account on Microsoft Windows is called Administrator. On Unix-like systems, it is called root instead. It's normally a bad idea to use an administrative account for anything that you can do with a less privileged account, because any time you use any user account at all you expose that particular account to potential threats if the software run under that account's privileges has a vulnerability that can allow someone to compromise the user account.

If you use Firefox to browse the Web, and it turns out Firefox has some kind of scripting vulnerability that allows a malicious script on a Website to install a backdoor on your system, how vulnerable you are depends to some degree on what user account you use:

  1. With a user account that has no administrative privileges, your user account may be compromised -- but the security cracker with access to it via the installed backdoor will only be able to access exactly what that user account can access.
  2. If you are logged in as the root user while using Firefox, the security cracker with access to the account via the installed backdoor may now have access to the entire system, because the root user has administrative privileges over everything.

Obviously, you have to access the administrative account from time to time when you are the system administrator. The key is to use those elevated privileges only for the specific tasks that require them, and sign back out of the root account immediately after that. On a server, this usually means logging in as root at a virtual TTY console, doing whatever you need to get done as root, then typing exit or <Ctrl>+<D> to log out of the root account again.

Using su

The "substitute user" or "switch user" command (also sometimes identified as "superuser"), su, allows convenient and secure access to the root account without having to log out of the current logged in user account on Unix-like systems. It is also commonly used to access normal, unprivileged user account environments from within a root account session by specifying the account whose user environment one wants to access.

Probably the most common use of su these days is as a means of accessing the root account to perform administrative tasks without leaving an X Window System session. One can just open a terminal emulator and type su, enter the password when prompted, and start working with root privileges.

This can provide additional security for remote connections too; the administrator can configure a system to disallow SSH logins as root, requiring a user to connect as some other user account and use su to elevate privileges. This is a quick and easy way to stop remote brute force attacks agains the root account's password. Some systems, such as FreeBSD, actually install SSH configured that way by default.

The convenience of being able to simply and securely achieve root privileges in a terminal emulator window -- without having to log out of your X Window System session, or even switch to a TTY console where you can't cut-and-paste the way you can in X -- is a great example of how interface design is security design. With the right security tool interface in place, the user is actually encouraged to do The Right Thing; in this case, the user is encouraged to log in as an unprivileged user for everyday tasks, rather than log in as root and stay there so a bunch of jumping through hoops doesn't have to go on before he or she can perform some trivial administrative task.

Using sudo

There is a great tool for securing and logging the behavior of users who need to perform limited administrative tasks called sudo (pronounced "sū dū"). Quite a lot can be done with this tool, and as such quite a lot can be said about it. It could, arguably, warrant a book of its own.

It is best used to allow specific users with specific, well-defined administrative privilege needs to do what they need to do, and only that; it also makes logging the activities of such users a breeze. If a user needs to be able to use the portaudit tool, he or she can be given access to its functionality that requires administrative privileges without exposing the rest of the capabilities reserved for the root user to the same user in the process. The sudo tool is essentially an excellent tool for delegating administrative tasks in a limited, secure, and logged (and therefore auditable) manner, so you don't have to start handing out the root password to everybody who wants to be able to mount a filesystem in the /mount directory.

What it is not as good at is replacing the root user account entirely. While the fact it allows easy logging of all administrative acitivity separated by actual user, rather than grouping all administrative task logging under the single heading of the root user, the same can be accomplished by creating separate superuser accounts; FreeBSD's toor user serves as an excellent example of this.

Of special concern is the fact that, if someone manages to compromise your unprivileged user account that has unlimited access to administrative privileges via sudo, that malicious security cracker may then find it significantly easier to access those privileges as well. This is an especially bad problem for systems where sudo is configured to allow passwordless use, of course.

The most worrisome problem with using it as a root replacement, however, is its complexity. As pointed out in Security, complexity, and the GUI environment, complexity is the enemy of security:

Every time you increase the complexity of a system, you increase the opportunity for something to go wrong in its design. The more lines of code in your system, the more opportunities there are to introduce bugs when developing the system; the more bugs there are, the more opportunities you have for bugs that introduce security vulnerabilities.

Because sudo is designed to do so much more than just give you easy access to administrative capabilities -- to provide fine-grained delegation of administrative privileges to otherwise unprivileged users -- its complexity is much more than that of a tool with a narrower purpose like su. Even configuring it properly can turn into a precarious exercise in safely navigating complexity, depending on how ambitious your needs get; many programs can be used to execute additional or external commands, and if a user is given root-level access to such a program via sudo without restrictions that prevent arbitrary execution of external commands, those commands could be executed with root privileges.

As Razvan Stoica explained in Sudo considered harmful, even a security conscious sysadmin who generally does things "right" for a given system can run afoul of the security damaging complexity of applying sudo too broadly to the problem of making system administration easy.

What else?

This is just a starting point. The most important part of security is being an active, security-minded thinker, and the "basics" of secure administrative privilege use should give you a foundation on which to build a deeper understanding of other aspects of secure system administration. Subjects of interest, that have not been addressed above, include an open-ended list of tools and techniques like the OpenSSH daemon's PermitRootLogin configuration option, system design considerations such as the quirks of the suid bit in file permissions, and an expanded understanding of the topics already covered above, exemplified by the proper management of the wheel group.

Such topics are incredibly important for system administrators, obviously. Even for end users, though, understanding topics like these can be invaluable. The better you understand your system, the better you can ensure you will not be part of the problem with system security.

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.

8 comments
Doug Vitale
Doug Vitale

I love this quotation that Chad provides: "Every time you increase the complexity of a system, you increase the opportunity for something to go wrong in its design. The more lines of code in your system, the more opportunities there are to introduce bugs when developing the system; the more bugs there are, the more opportunities you have for bugs that introduce security vulnerabilities." That about says it all. Regardless of which operating system you're using, you should turn off every background service that isn't needed for your personal/business requirements; you should disable as many applications as possible from running at boot up or logon, and the only applications that should be installed are the ones you actually need. To disable services in Windows, run "services.msc" from the Run menu. In Linux there are similar graphical interfaces in both Gnome and KDE. To disable certain apps from running when you boot up your Windows PC, use Autoruns: http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx

apotheon
apotheon

Part of my inspiration for this article was my dismay with the way Ubuntu misuses sudo -- and the way people actually argue it's somehow more secure than other, more traditional means of managing administrative privileges. I expect to take some flak for suggesting Ubuntu isn't the Second Coming of the mythic "perfect" OS, but that's a risk I'm willing to take. Someone has to say it.

pnoykalbo
pnoykalbo

edit /etc/pam.d/gdm uncomment out or add the following line: auth required pam_succeed_if.so user != root quiet

pnoykalbo
pnoykalbo

Tweak the /etc/ssh/sshd_config file Change the "PermitRootLogin" to "no" --------------------- # Authentication: #LoginGraceTime 120 PermitRootLogin no #StrictModes yes --------------------- then restart sshd service Other: Disable telnet Secure VNC (or do not use VNC)

Jaqui
Jaqui

both of us have said that before about Ubuntu. :D if they are to stupid to open their eyes, then they need to get screwed because of piss poor security design of the distro.

Tony Hopkinson
Tony Hopkinson

is windows appliance users, I always consider it interesting that a lot of the things they introduce to achieve that violate basic security principles. I know you can put su back togther in it, but out of the box it's less secure. In my eyes if they've done something like that in one place, they've done it in others, so I won't touch it.

Jaqui
Jaqui

it just isn't worth the effort to go though and fix their mistakes, when there are many distros that don't make those significant errors to choose instead.