Using Groups
One of the simplest ways to reduce the need for root is with groups. Unix-like operating systems classify users into groups, which consist of accounts of users who perform similar administrative functions. You can, for example, define a group named dnsadmins and add the accounts of every user who edits DNS zone files to that group. Then, by setting the permissions of the zone files and their directory appropriately, members of that group can edit zone files and reload the name server without the root password. The good news is that you could create such a group for almost any system function, and thereby avoid giving those users root access. Using groups in this manner is a powerful and often neglected system administration tool. I use groups for administering my own servers—just because I can use root doesn’t mean that I want to use root. Users can identify the groups they belong to by using id(1).
# id
uid=1000(mwlucas) gid=1000(mwlucas) groups=1000(mwlucas), 0(wheel), 2005(dnsadmin)
My UID is 1000, and my username is mwlucas. My GID, the primary group ID, is also 1000 and is also named mwlucas. I’m also in the wheel and dnsadmin groups.
The /etc/group File
The file /etc/group contains all group information. Each line contains four colon-delimited fields: the group name, password, ID number, and list of members.
wheel:*:0:root,mwlucas,pkdick
The group name is a human-friendly name for the group. This group is named wheel. Group names are completely arbitrary and you could call a group lickspittles if you want, but you should choose a name that gives an idea of the group’s purpose. While you might remember that lickspittles can edit the company web page, will that group name make any sense to your coworkers? If it does, you probably need better coworkers.
The second field, the group password, was a great theory that became an appalling practice once exposed to the real world. Modern Unix-like systems don’t do anything with the group password, but the field remains because old programs expect to find something here. The asterisk is just a placeholder to placate such software. (While OpenBSD could eliminate this field, some enterprises share /etc/group across operating systems.)
The third field gives the group’s unique numeric GID. Many programs use the GID rather than the name to identify a group. The wheel group has a GID of 0. The maximum GID is 232, or 4,294,967,296.
Last is a comma-separated list of all users in the group. As you can see, the users root, mwlucas, and pkdick are all members of the wheel group. To add users to a group, add their username to this list, but remember that no /etc/group entry can contain more than 200 users or be longer than 1024 characters.
Creating Groups
In order to create a new group, you need a name and GID number. OpenBSD usually assigns the next free GID to a newly created group with GIDs below 1000 reserved for OpenBSD. Programs included in OpenBSD that need a dedicated group ID use one below 1000. Software installed via the OpenBSD package system or ports (discussed in Chapter 13) assigns dedicated GIDs in the 500 to 1000 range. GIDs for user accounts start at 1000 and go up. If you create groups for special roles, start at a high GID so that these administrative groups will be obviously different from user accounts.
Groups, Unprivileged Users, and Group Permissions
The simplest way to create a new group is to use adduser to create an unprivileged user for the role, and use that user’s group to assign file permissions. As with any other unprivileged user, give this account the home directory /var/empty and a shell of nologin. Do not add this user to any other groups (especially not wheel). Lastly, let adduser disable the account. Sure, the shell will prevent logins, but an extra layer of defense won’t hurt.
Now that you have an administrative user and a group, you can assign file ownership. A user and a group own every file. To view the permissions on existing files, including hidden ones, use ls -la. (If you’ve forgotten how file ownership and permissions work, read ls(1) and chmod(1).) Many system administrators focus on file ownership and owner permissions, invest somewhat less time on worldwide permissions, and gloss over group permissions as if they don’t exist. Look closely at the sample DNS files that follow.
# ls -la
total 22
drwxr-xr-x 2 mwlucas wheel 512 Apr 16 22:02 .
drwxrwxrwt 8 root wheel 512 Apr 16 22:00 ..
-rw-rw-r-- 1 mwlucas mwlucas 14595 Apr 16 22:02 michaelwlucas.com.db
-rw-r----- 1 mwlucas wheel 198 Apr 16 22:02 rndc.key
This directory contains two files. The file rndc.key can be read and written by the user mwlucas; anyone in the wheel group can read rndc.key; and no one else can even read it. The file michaelwlucas.com.db can be read or written by the user mwlucas or anyone in the group wheel, but others can only read it. If you’re in the group mwlucas, you can edit this file.
Say I want my junior DNS administrators to be able to edit zone files but not be able to edit the rndc(8) configuration. The file permissions are correct, but I need the files to be owned by my DNS administrative user, dnsadmin. I also want my DNS admins to be able to create new zone files, so they need write permissions on the directory. Here’s how I would do that:
# chown dnsadmin:dnsadmin michaelwlucas.com.db # chgrp dnsadmin rndc.key # chown dnsadmin:dnsadmin . # chmod 775 . # ls -la total 22 drwxrwxr-x 2 dnsadmin dnsadmin 512 Apr 16 22:02 . drwxrwxrwt 8 root wheel 512 Apr 16 22:08 .. -rw-rw-r-- 1 dnsadmin dnsadmin 14595 Apr 16 22:02 michaelwlucas.com -rw-r--r-- 1 root dnsadmin 198 Apr 16 22:02 rndc.key
As you can see, these files are now owned by the user dnsadmin and the group dnsadmin. Anyone in the group dnsadmin should be able to edit michaelwlucas.com.db without using the root password. The user named—the unprivileged user for the DNS server—should be able to read both files. Add your DNS administrators to the dnsadmin group in /etc/group, and they should no longer need the root password to do their jobs.
This model has limitations, however. While your junior admins can’t accidentally edit rndc.conf, they can delete and replace it. It would be better to put that file in a directory they can read but not edit. And while our DNS administrators might think that they need the root password to restart the name server, they’re wrong. Use rndc(8) to manage the DNS server; other tasks can be managed via cron(8) or through sudo.