Unprivileged User Accounts
An unprivileged user account is a user account with no privileges to any programs or files. Many programs run as unprivileged users or use unprivileged users to perform specific duties. These unprivileged users get only the rights needed to perform a limited task.
“Only the rights needed to perform a limited task” sounds like every user account, doesn’t it? That’s true, but the account used by the least privileged human being still has more rights than many programs need. Any user with shell access usually has a home directory. Users can create files in their home directory, run text editors, process email, run scripts, and compile (if not install) software. An average shell user needs these minimal privileges, but programs do not. By having a program run as a very restricted user, you control the amount of damage the software or intruders can do to the system.
OpenBSD includes several unprivileged users out of the box. Take a look at /etc/passwd, and you’ll see accounts like sshd, named, _ntp, and so on. These are all unprivileged accounts used by specific server daemons. Examine them, and you’ll find several common characteristics.
Unprivileged users do not have normal home directories. Most share the home directory of /var/empty, which is owned by root and contains nothing except a logging socket. Having a home directory the user cannot write to makes the account less flexible, but is good enough for most server daemons. If these users do own files on the system, file permissions are usually set so that the user cannot write to them.
Similarly, no one should ever log in to the system with these accounts. If the named user account is reserved for the DNS subsystem, why would anyone actually need to log in as that account? Unprivileged users are assigned a shell that specifically forbids logging in: /sbin/nologin.
How does all this enhance system security? Let’s pick on the web server, a common intrusion vector, as an example. OpenBSD runs its web server as the user www. Suppose an intruder discovers a security flaw in your website and can use this to make the web server execute arbitrary code. This is a security nightmare; our intruder can now make the server program do absolutely anything within its power. But what, exactly, is within the web server’s power?
A command prompt permits much more mischief and mayhem than a website, so the intruder will probably try to access a command prompt on the system. The www user has a shell that specifically disallows a command prompt. While this doesn’t categorically prevent the intruder from getting a command prompt, it does make it much more difficult.
But our intruder is clever. Through really excellent intrusion skills, he makes the web server open a high-numbered port that dumps clients into a root shell. He now has access to a command prompt and can wreak untold damage … or can he?
He has no home directory, and no permissions to create one. Any files he wants to store must go into a globally accessible directory such as /tmp or /var/tmp, increasing his visibility. The web server configuration file is not owned by the www user. Even if the intruder has a path into the web server, he cannot reconfigure it. He can’t change the website files, as the www user doesn’t own them. The www user doesn’t have access to anything on the system, actually. Additionally, OpenBSD’s built-in web server chroots itself. Having broken into the web server program, the intruder now must escape the chroot and penetrate a privileged program.
Can he penetrate your system? Possibly, but it will be much more difficult. If he is specifically targeting you or your company, he might go to the trouble. If he is just looking for easy meat, however, he will probably give up and go bother someone running a Linux or Windows system.
Using unprivileged users doesn’t solve all security problems, mind you. The compromised www user can view web application source files. If your application is badly written or has database passwords hardcoded into hidden files, you’re still in trouble. But if you don’t use poorly written applications and you’ve kept your system updated and patched, the intruder will have a very hard time penetrating the rest of your server.
The nobody Account
The first unprivileged account was nobody. It was created for use by the Network File System (NFS, discussed in Chapter 9) to map files owned by root on foreign systems. Decades ago, people started using nobody as a generic unprivileged user, running web servers, proxy servers, and other daemons as nobody. While this was better than running those programs as root, it’s still poor practice. If an intruder penetrated one of those programs, he would gain access to all processes owned by nobody. Our hypothetical web server intruder would suddenly have access not only to the web server, but also to the database, NFS, or anything else running as nobody!
Every daemon that needs to run as a user needs its own unprivileged accounts—the whole point of using unprivileged users is to minimize the damage one piece of software can inflict. Use them liberally. OpenBSD provides discrete unprivileged users for services as small as finger(1) and the audio system. Follow this example.
_username
If you take a look at /etc/passwd, you’ll see that many unprivileged users have an underscore before their name, such as _syslogd, _ldapd, and _dhcp. This is an OpenBSD convention for identifying unprivileged users. Most add-on software also uses unprivileged usernames beginning with an underscore, such as _mysql and _postgresql.
Not all unprivileged usernames start with an underscore, however. Some of these are legacy users that OpenBSD retains for compatibility reasons, such as nobody. Others have a long history or support inflexible software, and changing them would be more annoyance than it’s worth.
The presence of an underscore means that a user is unprivileged. The absence of an underscore means nothing; the user might be a normal account or it might be unprivileged. If you create your own unprivileged users, you don’t need to include a leading underscore, but doing so will help other system administrators understand what the user does.
Creating Unprivileged Users
Here are common settings used for unprivileged users. You can change any of these as needed for your application.
-
username . Assign a username related to the user’s functions, so that you’ll easily recognize it. Giving an unprivileged user a username like
_fgcrlmight seem like a good way to conceal its purpose, but it will confuse your sysadmins and an intruder will quickly figure it out. -
home directory . /var/empty is a common setting for unprivileged users.
-
shell . /sbin/nologin is a common setting for unprivileged users.
-
UID/GID . Choose a specific range of UIDs and GIDs for your custom unprivileged users. OpenBSD reserves all UIDs below 1000 for system-assigned unprivileged users.
-
full name . Assign a name describing the user’s role.
-
password . Use
chpass(1)to assign the user a single asterisk as their encrypted password. This disables the account password.
These settings make your unprivileged user very unprivileged indeed. You can set all of these options except the password using adduser(8).
Now that you understand how to create, manage, and use user accounts, let’s discuss how to manage privileged users.
[13] This probably leaked through from the Microsoft culture, where for many years, every user had administrative access.
[14] Or you might not want to make this change. FTP transmits passwords in clear text, so you might want to use a separate password source for FTP connections. Why transmit passwords securely over one protocol, while transmitting them insecurely on a neighboring port?