User Configuration Basics

William L. Garner
 

Recently, I found myself in the position of explaining user configuration basics to two clients who, despite having run UNIX environments for some time, had failed to grasp some fundamental rules, concepts, and ideas of this task. Both clients had large numbers of users using a single home directory. Both clients had several group accounts, that is, accounts used by more than one person. Both clients had .rhosts files in every imaginable place. Before explaining the evils of these practices to my clients, I undertook some research so I could recommend some reading on the subject. I was quite surprised not to find an easily accessible document that adequately covers user configuration basics. Many system administration books discuss the mechanics of the process, but none adequately covers the rationale behind the mechanics. That is what this article is intended to do. The opinions expressed here are mine. Other rational minds may sometimes disagree.

The creation of a UNIX user account is not a complicated thing, yet very often it is not done completely or correctly. If not done completely and correctly, the user account may experience problems, be unsecure, or unstable. A complete user configuration includes the following steps:

1. An entry in /etc/passwd with all seven fields properly populated.

2. Group membership establishment.

3. A home directory with proper permissions and ownership.

4. Startup scripts in the home directory with proper ownership and permissions.

5. Creation of trust files with proper ownership and permissions.

6. Special abilities: ftp/at/cron considerations.

The execution of the aforementioned steps is adequately documented in a variety of places. Our concern is the thinking behind the steps.

The creation of the entry in /etc/passwd for a new user is a simple process of adding a record consisting of seven colon delineated fields. The first field is that of the User Name. There are a number of schools of thought regarding the construction of the user name. One school maintains that the user name should be constructed from the components of the user's actual name. W.L. Garner, for example, might be used to construct "wlgarn" as a user name. A second approach is the arbitrary creation of a "handle". W.L. Garner might be user "falcon". A third approach is the creation of what are sometimes referred to as "A-Numbers". Garner's user name might then be "A4214".

Each approach has advantages and drawbacks. The principle disadvantage of the first method is that that theft of a phone book will provide the raw data necessary to construct valid user names. This, obviously, is a potential security problem. The advantage to this approach is that a user is unlikely to forget their name. The second approach has a similar weakness. Names chosen in this manner are often easily guessed, or already common knowledge. The final approach is generally regarded as the most secure. It has no pre-existing association with the actual user and its construction can be varied. The disadvantage is that users must remember their "A-Number". The counter to that concern is that if a user isn't smart enough to remember the "A-Number", then they probably shouldn't have an account anyway.

After the User Name field in /etc/passwd comes the password field. This field should never be left open or blank. To leave it blank is to create an unprotected account. An unprotected account is never acceptable. While creating the account, obviously, you can not hand code an encrypted password into this field. You can, however, set the password immediately after creating the account. This must be done. Never, ever leave an account unprotected even for 5 minutes. Make the setting of the password a ritual thing.

Following the password field is the UID field. UID stands for User Identification. While we humans may refer to user garner, the UNIX operating system knows only UID 4332. UNIX makes no use of the user name, other than in the passwd file and in output displays of ls. Just as having two friends named John can sometimes lead to disastrous confusion, having two users with a UID of 4332 will cause similar confusion. Consequently, it should be written in stone that: a) UID numbers will be unique; b) users will never be removed from /etc/passwd; and c) UIDs will never be "reused". These rules should be written in stone because if you have unique UID numbers, do not remove user from /etc/passwd1, and do not "reuse" UID numbers, you will never encounter confusion relating to user identification and ownership issues.

It can be argued that there are ways to break these rules and still have everything work properly. True, it can be done and as in the case of sites like Universities with high rates of turnover in users, sometimes it must be done. In these cases, it is all the more critical to establish standards and procedures for doing this because the potential for trouble will always be there. Keep in mind that one of the keys to success in systems administration is to make it easier to be right than it is to be wrong. For the vast majority of sites, reusing UID numbers is not a good idea. None the less, there will be people at these sites who will still insist on removing users from /etc/passwd and reusing the UID number. If you are a consultant, follow them around. you will make a great deal of money fixing what they break.

The fourth field is the GID. This is the Group Identification number, where the association between the user and his/her/its principal group is made. A user can be a member of a number of groups, switching at will, or belong to all at once. This multiple association is made in the /etc/group file. The functionality afforded by groups is that it allows you to grant groups of people/users access to files for which they share a common need.

The fifth field is the GECOS field. Conventional wisdom used to prescribe certain contents for this field. These contents included the user's actual name, phone number, office location, etc. The rise of the Internet, however, changed this. Current thinking is that this field should be empty except for three commas. The giving away of names, phone numbers, and office locations makes it too easy for someone to determine who is on vacation, out sick, etc. finger uses the /etc/passwd file for its information, so expect some complaints when finger no longer provides that information. Accept the complaints with a smile, and keep the information out of /etc/passwd.

The sixth field establishes the location of the user's home directory. This is the directory in which the user finds himself when he logs in. An analogy can be made to a user's desk. It is the place where the user works - a place to store things, a filing cabinet, pens. Just as desks are usually equipped with locks, a user's home directory should be secured. That is, the user should own that directory, and it should not be writable by anyone else. This is one of the only places where a user should be able to create files and directories.

One of the problems with group accounts is that the home directory is shared. Files created here could have been created by any of the group of people using that account. Which person actually created the file? No way to tell. It is in the home directory that users will find their configuration and startup files. The ownership of these files, and the permissions on them, should reflect your policy. At some sites, the user owns the .profile and other startup scripts as well as the configuration files found in the home directory. One advantage to having someone other than the user own those files, is that the user can be prevented from modifying or changing the files. This can be important where users are supposed to be "captive". That is, they log in and go directly into an application. Additionally, it may be important to have someone other than root own "trusting" files, so that their unauthorized modification can be prevented. Another way to make a "captive" user is to ensure that they never exit the .profile except to logout. Any application that is called must have no user exits or shell escapes.

The seventh field defines the user's default shell. This is the executable shell that the user's account uses when the user logs in. Accounts that are enabled should have a functional shell here. Accounts that are disabled should have a non-functional shell here. If users are not allowed to change their default shell, then the execution bit for world and group should be removed from the chsh command. Also, ensure that the /etc/shells file is populated. This file defines the "legal" shells for your environment.

"Trusting" files are those that create a trust relationship. In particular, .rhosts creates a "trust" relationship with the servers whose names appear in the file. The functionality of .rhosts is that a user coming from a "trusted" machine will not be required to enter a password when using remsh or rlogin. The remote machine trusts the authentication performed on the other machine. Thus, a user can acquire unauthenticated access to a machine. This is not a good thing. In the vast majority of cases, the justification for the existence of a .rhosts file is convenience. Usually, someone just doesn't want to type a password. They may give you all sorts of other reasons for the existence of the .rhosts, so it is important to dig deeply and see if there is not a more secure means to meet the user's requests. In some cases, there will be a legitimate need for a .rhosts file. Document this need extensively. Also document why other options won't meet the need. Watch this account closely, and make sure that security on the trusted machine is good. The existence of a .rhosts file is a major vulnerability. Although the exposure can be minimized, it is still exposure.

Some sites will place an empty .rhosts file in every home directory. This file will be owned by root and not writable by anyone. The same is done for the .**rc files. Create them; have root own them; remove write permissions. By doing this, you prevent someone else from creating these files. However, as long as the user owns the directory, they can remove the files and create new ones. In such cases, other measures must be taken.

There are a number of detail-oriented tasks that must accompany the creation of a new account. If the account does not require ftp ability, then the user should be added to the /etc/ftpusers file. This file works backward from what would seem intuitive. Inclusion of a user name in the file prevents ftp capability. Depending on your position regarding at and cron allow/deny files, it may be necessary to add the user name to one or both of these files. In any case, users should be explicitly granted or denied access to cron and at.

In any discussion regarding users, the subject of the "root" account should be covered. Because of root's awesome power and responsibility in the environment, it is sometimes overlooked that root is, still, a user. A very powerful user, but none the less, a user. As such, root, more than the ordinary user, should enjoy a very protected home environment. Many platforms will allow you to move root's home directory from / to something more in keeping with the standard home directory configuration for your site. If all of your user's home directories are in /home, then root's home should be /home/root. Just like other user, /home/root should be owned by the user, that is, root. It should be readable and writeable only by the owner. Its .profile should be owned by root, read and writable only by the owner. An empty .rhosts, owned by root, should exist, readable and writable only by the owner.

Some platforms will not be candidates for configuring root in this manner. The moving of root's home directory to a file system that may not be mounted during a boot to single user may cause problems. Before you configure your root environment in this manner, make sure that your platform will not have problems. In cases where root cannot be configured in this way, it is recommended that a directory for root be created in the same manner as described above, and that root use it as a repository for root's scripts, output, etc. The / directory is not the place for root's scripts and output files. Keep /clean.

Root should be restricted to logging in at the console. Furthermore, ensure that the console is in a restricted area. Root should be a rarely used account. Systems administrators should not routinely use the root account for activity that does not require root authority. To do so invites disaster. Access to the root account should be made via su. This ensures that there is a trail of who has used root. Additionally, it gives you an opportunity to detect unauthorized root activity. Root's password should be a closely held secret. If you have more than one person who needs root authority, investigate the acquisition of a "root delegation" tool. These tools will allow you to selectively and auditabily grant root authority to users other than root. This will go a long way toward helping you secure root access.

Now that I've covered some of the specific "do's", here are a few "don'ts". Because the actual list of things not to do is almost infinite, consider this a short list.

Do not share home directories. It's never a good idea. It doesn't save appreciable disk space. It doesn't simplify user administration. It destroys accountability and security.

Do not allow "group" accounts. A group account is any account that has more than one person accessing it. This also destroys accountability and security. I have heard every imaginable reason for a group account, and have yet to encounter one that is valid. The group functionality was put in UNIX for a reason. Use it. If that isn't enough, use ACLs. If you can't get the functionality via permissions and ACLs, then look at the business process. Just as a bank makes sure that each teller works out of his or her own drawer, you must make sure that each user works out of his or her own account. Accountability is vital not only to determine who did what, but also vice versa.

Do not grant ftp capability to root. Root must be the most secure account on the machine. If you need to ftp something, do it under your personal account. Don't do it as root.

Do not take shortcuts. Do it right the first time. Shoot anyone who cuts and pastes between /etc/passwd files.

Control-D

User administration can be a mind-boggling task at larger sites and a pain in the neck at smaller sites. The use of standards in user configuration will help make this task more manageable, and make it easier to teach to new administrators. It will improve your ability to identify backup requirements for your environment. Standard user configuration will also help you prepare your site to become more secure. Despite a seemingly endless list of reasons to adopt standards, you will inevitably encounter someone who wants to re-invent user administration standards. If you are a consultant, greet them warmly and follow them around. Remember, fixing what they break will make you a lot of money.

About the Author

William Garner has been a working system administrator for fifteen years. As President of the North American Performance Group, he has built an organization of hard-core system administrators solving problems related to system administration, performance and security for clients across North America. He can be reached at wlgarner@napg.com.