Unix: Controlling privileged access

One of the most important things you can do for security on a Unix system is restrict root access. But the issue is more complicated than who knows root's password.

If your job involves protecting the security of Unix servers, you need to know about and verify the various ways that people can exercise root (i.e., superuser) privilege. This is especially true of you find yourself inheriting the systems administrator role from other people. A quick check of a handful of issues can help you be sure your view of security on the

servers is realistic.

Who has root access?

If the answer is "nobody but you", that's a great starting point, but you should still change root's password periodically. In addition, you should store it in a safe place -- maybe a secure password tool such as Keepass, maybe in an actual safe. One of my bosses from decades ago had me write down the root passwords we used on our large Solaris network and put them in a safe that nearly no one had access to. In case I got run over by a back hoe, someone would be able to keep our servers up to snuff.

How do they have it?

Root access is possible even if you don't know root's password, so you shouldn't run off thinking you've closed off others' access to this privilege just because you changed the root password to "N01canGuessMe@all!". Check the /etc/sudoers file to see if root privileges have been granted through it. Individuals might be able to run specific commands as root or might be able to use the command "sudo su -" and simply assume root's identity. When they do this, of course, they will be prompted to enter a password but not root's -- their own.

Can they log in as root?

The worst thing about anyone being able to log in directly as root is that you then have no accountability for what these individuals' do when logged in as root. All you know is that someone logged in as root on Saturday night after 11 PM and maybe what they did -- or maybe not. Legitimate users should log in as themselves and switch user to root when they need to make changes to the system that they cannot do with their own privileges. If you have coworkers who help out administering your Unix systems and they perform only a limited set of tasks, you might give them just the necessary privileges. Maybe they can add or remove accounts or reboot the servers, but nothing else.

To prevent direct logins as root, set root's shell to /sbin/nologin in the /etc/passwd file. Verify that /sbin/nologin exists on your system as this might not work on all Unix systems. Verify this works before you log off. You should still be able to su to root.

Root's UID is 0

When looking into who has root access on a Unix system, don't forget the root privilege is associated with the UID 0. If you have another user set up on your system who also has his UID set to 0, that person will have root privileges when he or she logs in. Don't be fooled.

justme:x:0:2000:Jane Doe:/home/jdoe:/bin/bash

Who has access via the sudoers file?

The sudoers file has many options for granting access. It can be very strict; for example, you can give a user the right to run a single command only on a specific system. Or it can be very loose; for example, you can give a group of users the ability to switch user to root and, then, do anything they want with the authority of the superuser.

This line gives the admin group on the server called "boson" the ability to upgrade software.

%admin boson=(root)NOPASSWD:/usr/bin/apt-get update,/usr/bin/apt-get upgrade

This line, on the other hand, gives everyone in the admin group the right to run any command as root.

%admin ALL=(ALL) ALL

To find out who is the in wheel group, look in the /etc/group file, but keep in mind that users may be members of the wheel group through their /etc/passwd file entries.

# grep wheel /etc/group
# grep :10: /etc/passwd
samq:x:1234:10:Sam Quibly:/home/samq:/bin/bash

To see if special privileges are given to the wheel group (this is not uncommon), look at the /etc/sudoers file. It's best practice, though, to read and understand the entire file if you want to know who can do what.

# grep wheel /etc/sudoers
# Uncomment to allow people in group wheel to run all commands
%wheel        ALL=(ALL)       ALL

When was root's password last changed?

To check when root's password was last changed, pull root's record out of the /etc/shadow file.

grep ^root: /etc/shadow

The first numeric field (after the password hash) shows you the date that the password was last changed, but in a format that represents that date as the number of says since January 1, 1970 -- a very Unix-like thing to do since it represents the Unix "epoch" before which computers really weren't all that hot. If it looks like what you see above, don't panic. Do a simple calculation. First, display today's date in that same format using the command echo $(($(date +%s)/86400)). Then use an expr command to see how many days have passed since the password was last set.

# grep root /etc/shadow
# echo $(($(date +%s)/86400))
# expr 16279 - 15960

In this case, it's been nearly a year since root's password was last set. Even if you're the only one who knows the root password, it's better to change it periodically in case any type of system compromise has left the hash in someone else's possession. You don't want anyone to have plenty of time to see what they can do with that information.

Who has access from other systems?

Another thing to look out for when you're trying to judge the vulnerability of a Unix system is who has access from other systems. If the server you are examining trusts root on other systems, anyone with root access to those servers will be able to assume root on your server. Look for a file called ~root/.ssh/authorized_keys. That might be /.ssh/authorized_keys or /root/.ssh/authorized_keys depending on the version of Unix that you are running.

Wrap Up

Whatever you do, don't give root a flimsy password. Consider 15 characters or more to be a rule of thumb. And send yourse;f reminders to change the password every 2-3 months at a minimum.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT