Using Groups to Avoid Using Root

In addition to being a security concern, the root password distribution policy can cause contention in any organization. Many sysadmins hate giving out the root password, even to people who are responsible for maintaining part of the system. If this sort of sysadmin doesn't know how to properly manage the computer, this reluctance can prevent people from doing their jobs. Many other sysadmins hand out root to dang near anyone who wants it and then complain when the system becomes unstable. Both attitudes are untenable in the long run, especially when UNIX has powerful facilities for removing the need to use the root password.

One common situation is where a junior administrator is responsible for a particular portion of the system. I've had many DNS administrators work under me; these people don't ever install software, recompile the kernel, or do other low-level system tasks. They just answer emails, update zone files, and reload named. New junior admins frequently seem to think that they need root access to do this sort of work. By establishing your own groups, consisting of users who perform similar administrative functions, you can let people do their jobs without the root password. In this section, we'll implement group-level access control over nameserver files. The same principles apply to any files you should choose to protect. (Mail and web configuration files are other popular choices for this sort of delegation.)

OpenBSD has reserved user accounts for use by programs integrated with the system. For example, the nameserver runs under the user account called "named" and the group "named." As we covered earlier, if an intruder compromised the nameserver, she could only access the system with the privileges of the nameserver user. You can create a group called "dns" that includes the people who manage your nameserver. Do not use the program user for this sort of work! While you want programs run by the user named to be able to read files owned by the group "dns," you do not want the nameserver program to be able to write to files owned by the dns group. This further minimizes the damage a nameserver daemon compromise could inflict.

The simplest way to create a group to own files is to create a user to own them, and use that user's primary group as the group of the files. Adduser(8) will let you create a user to own these files. Because we already have a user "named," we'll call this administrative user "dns." The name isn't that important, but you should choose a name that you'll be able to remember easily.

 # adduser -silent Enter username [a-z0-9_-]: dns Enter full name []: DNS Administration User Enter shell csh ksh nologin sh [csh]: nologin 

Give your administrative user a shell of "nologin," which gives the user the shell of /sbin/nologin. Nobody can log in with this account.

 Uid [1001]: 

If you want, you could specify a particular uid for these sorts of users. I've been known to choose uid numbers close to those used by the users for their related programs. For example, named has a uid of 70. I could decide to give dns a uid of 1,070 to keep some sort of relationship between my private system users and those used by OpenBSD. Remember, user IDs below 1,000 are reserved for OpenBSD's internal use.

 Login group dns [dns]: Login group is ``dns''. Invite dns into other groups: guest no [no]: 

The whole point of this sort of user is that they have their own group. Under no circumstances should you add such an administrative user to another group!

 Enter password []: Set the password so that user cannot logon? (y/n) [n]: y 

Just hit return when you're asked for a password for this user, and adduser will give you a chance to set up the password so the user cannot log on. This is what you want; this administrative user should never need to log on for any reason.

Now that you have an administrative owner and a group for it, you can assign ownership of files to that user. A user and a group own every file. You can see existing file ownership and permissions with "ls -l". ^[4] Many new sysadmins pay close attention to the owner, and to the world permissions, but only skim the group permissions.

 # ls -l total 29 -rw-rw-r--  1 root  wheel   27136 Sep 14 09:36 file1 -rwxrwxr--  1 root  wheel    1188 Sep 14 09:35 file2 # 

Here, file1 can only be read or written to by root or members of the group wheel, but can be read by anyone. Root or any member of the group wheel can read file2. If you're in the wheel group, you don't need to become root to edit or read file2 file; you can just open your text editor and go!

To change the owner of a file, use chown(1). To change a group owner on a file, use chgrp(1). Both take the same syntax; the name of the new owner and the filename.

 # chown dns file1 # chgrp dns file1 # ls -l file1 -rw-rw-r--  1 dns dns   27136 Sep 14 09:36 file1 # 

This file is owned by the user dns and in the group dns. Anyone who is in the dns group can read and write to this file, without using the root password. Finally, this file can be read by the nameserver. Add your junior administrators to the dns group in /etc/group, and abruptly they can edit files owned by the dns group without the root password.

The only thing the DNS administrators might need the root password for now is to restart the nameserver. This is easily dealt with by setting up a cron job to reload the nameserver on a regular basis. These admins still might want to reload the nameserver manually on special occasion, however. That's where sudo comes in.

^[4]If you forget how UNIX permissions work, take a look at ls(1).