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:
- 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.
- 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.
exit or + 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. 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. 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 such 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.