From the system's point of view, auser isn't necessarily an individual person. Technically, to the operating system, a user is an entity that can execute programs or own files. For example, some user accounts exist only to execute the processes required by a specific subsystem or service (and own the files associated with it); such users are sometimes referred to as pseudo users. In most cases, however, a user means a particular individual who can log in, edit files, run programs, and otherwise make use of the system.
Each user has a username that identifies him. When adding a new user account to the system, the administrator assigns the username a user identification number (UID). Internally, the UID is the system's way of identifying a user. The username is just mapped to the UID. The administrator also assigns each new user to one or more groups: a named collection of users who generally share a similar function (for example, being members of the same department or working on the same project). Each group has a group identification number (GID) that is analogous to the UID: it is the system's internal way of defining and identifying a group. Everyuser is a member of one or more groups. Taken together, a user's UID and group memberships determine what access rights he has to files and other system resources.
User account information is stored in several ASCII configuration files:
We'll consider each of these files in turn.
6.1.1 The Password File, /etc/passwd
The file /etc/passwd is the system's master list of information about users, and every user account has an entry within it. Each entry in the password file is a single line having the following form:
The fields are separated by colons, and blank spaces are legal only within the user information field.
The meanings of the fields are as follows:
Multiple user accounts with the same UID are the same account from the system's point of view, even when the usernames differ. If you can, it's best to keep UIDs unique across your entire site and to use the same UID for a given user on every system to which he is given access.
Here is a typical entry in /etc/passwd:
This entry defines a user whose username is chavez. Her UID is 190, her primary group is group 100, her full name is Rachel Chavez, her home directory is /home/chavez, and she runs the enhanced C shell as her command interpreter.
Since /etc/passwd is an ordinary ASCII text file, you can edit the file with any text editor. If you edit the password file manually, it's a good idea to save a copy of the unedited version so you can recover from errors:
# cd /etc # cp passwd passwd.sav Save a copy of the current file # chmod go= passwd.sav Protect the copy (or use a umask that does this) # emacs passwd
If you want to be even more careful, you can copy the password file again, to something like passwd.new, and edit the new copy, renaming it /etc/passwd only when you've successfully exited the editor. This will save you from having to recopy it from passwd.sav on those rare occasions when you totally munge the file in the editor.
However, a better tactic is to use the vipw command to facilitate the process, allowing it to be careful for you. vipw invokes an editor on a copy of the password file (traditionally /etc/ptmp or /etc/opasswd, but the name varies). The presence of this copy serves as a locking mechanism to prevent simultaneous password-file editing by two different users. The text editor used is selected via the EDITOR environment variable (the default is vi).
When you save the file and exit the editor, vipw performs some simple consistency checking. If this is successful, it renames the temporary file to /etc/passwd. On Linux systems, it also stores a copy of the previous password file as /etc/passwd.OLD (Red Hat) or /etc/passwd- (SuSE).
The vipw command also has the advantage that it automatically performs or reminds you about other related activities that are required to activate the changes you just made. For example, on Solaris systems, it offers you the chance to edit the shadow password file as well. More importantly, on FreeBSD and Tru64 systems, it automatically runs the binary password database creation command, which turns the text file into the binary format used on those systems (pwd_mkdb and mkpasswd, respectively).
AIX does not provide vipw.
6.1.2 The Shadow Password File, /etc/shadow
Most Unix operating systems support a shadow password file : an additional user-account database file designed to store the encrypted passwords. On most systems, the password file must be world-readable in order for any command or service that translates usernames to/from UIDs to function properly. However, a world-readable password file means that it's very easy for the bad guys to get a copy of it. If the encrypted passwords are included there, a password cracking program could be run against them, and potentially discover some poorly chosen ones. A shadow password file has the advantage that it can be protected against anyone accessing it except the superuser, making it harder for anyone to acquire encoded passwords (you can't crack what you can't get).
Here are the locations of the shadow password file on the various systems we are considering:
HP-UX and Tru64 store encoded passwords in the protected password database when enhanced security is installed (as we will see). Tru64 also has the option of using a traditional shadow password file with the enhanced security package.
At present, entries in the shadow password file typically have the following syntax:
username is the name of the user account, and encoded password is the encoded user password (often somewhat erroneously referred to as the "encrypted password"). The remaining fields within each entry are password aging settings. These items control the conditions under which a user is allowed to and is forced to change his password, as well as an optional account expiration date. We will discuss these items in detail later in this chapter.
The SuSE Linux version of the vipw command accepts a -s option with which to edit the shadow password file instead of the normal password file. On other systems, however, editing the shadow password file by hand is not recommended. The passwd command and related commands are provided to add and modify entries within the file (as we shall see), a task which can also be accomplished via the various graphical user account management tools (discussed later in this chapter).
188.8.131.52 The FreeBSD /etc/ master.passwd file
FreeBSD uses a different password file, /etc/master.passwd, which also functions as a shadow password file in that it stores the encoded passwords and is protected from all non-root access. FreeBSD also maintains /etc/passwd.
Here is a sample entry from master.passwd:
ng:encoded-pwd :194:100:staff :0 :1136005200 :J. Ng:/home/ng:/bin/tcsh
Entries in this file include three additional fields sandwiched between the GID and user's full name (highlighted in the example entry): a user class (see Section 184.108.40.206, later in this chapter), the password expiration date, and the account expiration date (the latter are expressed as seconds since midnight on January 1, 1970 GMT). In this case, user ng is assigned to the staff user class, has no password expiration date, and has an account expiration date of June 1, 2002. We'll consider these fields in more detail later in this chapter.
220.127.116.11 The protected password database under HP-UX and Tru64
Systems that must conform to the C2 security level (a U.S. government-defined system security specification) have additional user account requirements. C2 security requires many system features, including per-user password requirements, aging specifications, and nonaccessible encoded passwords. When the optional enhanced security features are installed and enabled on HP-UX and Tru64 systems, a protected password database is used in addition to /etc/passwd. (It is part of theTrusted Computing Base on these systems.)
Under HP-UX, the protected password database consists of a series of files, one per user, stored in the /tcb/files/auth/x directory hierarchy, where x is a lowercase letter. Each user's file is placed in a file named the same as his username, in the subdirectory corresponding to its initial letter: chavez's protected password database entry is /tcb/files/auth/c/chavez. On Tru64 systems, the data is stored in the binary database /tcb/files/auth.db.
The HP-UX files are structured as authcap entries (just as terminal capabilities are specified via termcap entries on some systems), consisting of a series of colon-separated keywords, each of which specifies one particular account attribute (see the authcap manual page for details).
All of this is best explained by an excerpt from chavez's file:
The entry begins with the username to which it applies. The u_name field again indicates the username and illustrates the format for attributes that take a character string value. The u_id field sets the UID and illustrates an attribute with a numerical value; u_pwd holds the encoded password. The u_lock and u_pickpw fields are Boolean attributes, for which true is the default when the name appears alone; a value of false is indicated by a trailing at-sign (@). In this case, the settings indicate that the account is not currently locked and that user chavez is allowed to select her password. The chkent keyword completes the entry.
Table 6-1 lists the fields in the protected password database. Note that all time periods are stored as seconds, and dates are stored as seconds since the beginning of Unix time (although the tools for modifying these entries will prompt for days or weeks and actual dates).
All of the available fields are documented on the prpwd manual page.
System default values for protected password database fields are stored in /etc/auth/system/default under Tru64 and /tcb/files/auth/system/default under HP-UX. The values in users' records hold changes with respect to these settings. In addition, these system-wide defaults may be set in the default file:
It is not necessary to edit the protected password database files directly. Indeed, the relevant manual pages discourage you from doing so. Instead, you are encouraged to use the graphical utilities that are provided. Doing so is often helpful because these tools describe the various settings in a more understandable form than the corresponding field name alone provides. Nevertheless, there will be times when examining the entry for a particular user is the best way to diagnose a problem with an account, so you'll need to be able to make some sense of these files. We'll consider the most important of them when we discuss password management later in this chapter.
6.1.3 The Group File, /etc/group
Unix groups are a mechanism provided to enable arbitrary collections of users to share files and other system resources. As such, they provide one of the cornerstones of system security.
Groups may be defined in two ways:
The best administrative practice is to define all groups explicitly in the /etc/group file, although this is not required except under AIX.
Each entry in /etc/group consists of a single line with the following form:
The meanings of these fields are as follows:
Here are some typical entries from an /etc/group file:
chem:!:200:root,williams,wong,jones bio:!:300:root,chavez,harvey genome:!:360:root
The first line defines the chem group. It assigns the group identification number (GID) 200 to this group. Unix will allow all users in the password file with GID 200 plus the additional users williams, wong, jones, and root to access this group's files. The bio and genome groups are also defined, with GIDs of 300 and 360, respectively. Users chavez and harvey are members of the bio group, and root is a member of both groups.
The various administrative tools for managing user accounts generally have facilities for manipulating groups and group memberships. In addition, the group file may be edited directly.
On Linux systems, the vigr command may be used to edit the group file while ensuring proper locking during the process. It works in an analogous way to vipw, creating a temporary copy of the group file for actual editing, and saving a copy of the previous group file when modifications are complete.
Most Unix systems impose a limit of 16 (or sometimes 32)group memberships per user. Tru64 also limits each line in /etc/group to 225 characters. However, group definitions can be continued onto multiple lines by repeating the initial three fields.
18.104.22.168 User-private groups
Red Hat Linux uses a different method, known as user-private groups (UPGs), for assigning user primary group membership. In this scheme, every user is the sole member of a group with the same name as his username, whose GID is the same as his UID. Users can then be added as additional members to other groups as needed.
This approach is designed to make project file sharing easier. The goal is to allow a group of users, say chem, to share files in a directory, with every group member being able to modify any file. To accomplish this, you change the group ownership of the directory and its files to chem, and you turn on the setgid permission mode for the directory (chmod g+s), which causes new files created there to take their group ownership from the directory rather than the user's primary group.
The dilemma for this line of reasoning comes when deciding how group write access should be enabled for files in the shared directory. UPG proponents argue that this needs to be accomplished automatically by using a umask of 002. However, the side-effect of this convenience users not having to explicitly assign write permission to files they want to share means that other files the user creates (e.g., ones in his home directory) will also be group-writeable, a very undesirable outcome for security reasons. The "solution" is to make the user's primary group a private group, to which granting write access is benign or irrelevant, since the group is equivalent to the user.
In the end, however, UPGs are deeply embedded within the Red Hat Linux way of doing things, so administrators of Red Hat systems must learn to live with them.
6.1.4 Dynamic Group Memberships
In most cases, Unix does not distinguish between the two ways of establishing group membership; exceptions are the group ownership of new files and accounting data records, both of which generally reflect/record the current primary group membership. In other contexts for example, file access a user is simultaneously a member of all of her groups: her primary group and all of the groups for which she is listed as an additional member in /etc/group.
The groups command displays a user's current group memberships:
$ groups chem bio phys wheel
The groups command will also take a username as an argument. In this case, it lists the groups to which the specified user belongs. For example, the following commands lists the groups of which user chavez is a member:
$ groups chavez users bio
In a few circumstances, the group that is the user'sprimary group is important. The most common example is accounting systems where resource usage is tracked by project or department in addition to user. In such contexts, the primary group is typically the one that is charged for a user's resource use.
For such cases, a user can temporarily change the group designated as her primary group by using the newgrp command:
$ newgrp chem
The newgrp command creates a new shell for this user, setting the primary group to be chem. Without an argument, newgrp resets the primary group to the one specified in the password file. The user must be a member of the group specified as the argument to this command.
FreeBSD does not support changing the primary group and so does not provide newgrp.
The id command can be used to display the currently active primary and secondary group memberships:
$ id uid=190(chavez) gid=200(chem) groups=100(users),300(bio)
Current primary group membership is indicated by the "gdocSection3Title">22.214.171.124 The Linux group shadow file, /etc/gshadow
On Linux systems, an additional group configuration file is used. The file /etc/gshadow is the group shadow password file. It contains entries of the form:
where group-name is the name of the group, and encoded password is the encoded version of the group password. group-admins is a list of users who are allowed toadminister the group by changing its password and modifying memberships within the group (note that being so designated does not make them members of the specified group). additional-users is almost always a copy of the additional group members list from /etc/group; it is used by the newgrp command to determine which users can designate this group as their primary group (see below). Both lists are comma-separated and may not contain spaces.
Here are some sample entries from a group shadow file:
The group drama has a group password, and users langtree and siddons are members of it (as are any users who have it as their primary group, as defined in /etc/passwd). Its group administrator is user foster (who may or may not be a member of this group). In contrast, group bio has a disabled group password (since an asterisk is not a valid encoding for any password character), root is its group administrator, and users root, chavez, and harvey are additional members of the group.
The SuSE version of the vigr command accepts a -s option in order to edit the shadow group file instead of the normal group file.
On Linux systems, the newgrp command works slightly differently, depending on the group's entry in the group password file:
126.96.36.199 The HP-UX /etc/logingroup file
If the file /etc/logingroup exists on an HP-UX system, its contents are used to determine the initial group memberships when a user logs in. In this case, the additional members list in the group file is used to determine which users may change their primary group to a given group with newgrp. Common sense dictates that the additional members list in the logingroup file be a superset of the list in the corresponding entry in /etc/group.
188.8.131.52 AIX group sets
AIX extends the basic Unix groups mechanism to allow a distinction to be made between the groups a user belongs to, which are defined by the password and group files, and those that are currently active. The latter are referred to as the concurrent group set; we'll refer to them as the "group set." The current real group and group set are used for a variety of accounting and security functions. The real group at login is the user's primary group, as defined in the password file. When a user logs in, the group set is set to the entire list of groups to which the user belongs.
The setgroups command is used to change the active group set and designated real group. The desired action is specified via the command's options, which are listed in Table 6-2.
For example, the following command adds the groups phys and bio to the user's current group set:
$ setgroups -a phys,bio
The following command adds phys to the current group set (if necessary) and designates it as the real group ID:
$ setgroups -r phys
The following command deletes the phys group from the current group set:
$ setgroups -d phys
If the phys group was also the current real group, the next group in the list (in this case system) becomes the real group when phys is removed from the current group set. Note that each time a setgroups command is executed, a new shell is created.
Without arguments, setgroups lists the user's defined groups and current group set:
$ setgroups chavez: user groups = chem,bio,phys,genome,staff process groups = phys,bio,chem
The groups labeled "user groups" are the entire set of groups to which user chavez belongs, and the groups labeled "process groups" form the current group set.
6.1.5 User Account Database File Protections
Proper file ownership and protection on the us er accounts database files are extremely important to maintaining system security. All of these files must be owned by root and a system group such as GID 0. The two shadow files should also prevent access by anyone but their owner. root may have write access to any of these files.
Apply the same ownership and protection to any copies of these files you make. For example, here is a long directory listing of the various files from one of our systems:
# ls -l /etc/pass* /etc/group* /etc/*shad* -rw-r--r-- 1 root root 681 Mar 20 16:15 /etc/group -rw-r--r-- 1 root root 752 Mar 20 16:11 /etc/group- -r--r--r-- 1 root root 631 Mar 6 12:46 /etc/group.orig -rw-r--r-- 1 root root 2679 Mar 19 13:15 /etc/passwd -rw-r--r-- 1 root root 2674 Mar 19 13:15 /etc/passwd- -rw------- 1 root shadow 1285 Mar 19 13:11 /etc/shadow -rw------- 1 root shadow 1285 Mar 15 08:37 /etc/shadow-
We made a copy of the group file (group.orig) which we protected against all write access. The files with the hyphens appended to their name are backup files created by the vipw and vigr utilities. Whatever the specific files present on your system, ensure that all of them are protected properly, and make doubly sure that no shadow file is readable by anyone but the superuser.
6.1.6 Standard Unix Users and Groups
All Unix systems typically predefine many user accounts. With the exception of root, these accounts are seldom used for logins. The password file as shipped usually has these accounts disabled. Be sure to check the shadow password file on your system, however. System accounts without passwords are significant security holes that should be plugged right away.
The most common system user accounts are listed in Table 6-3.
Unix systems are similarly shipped with a /etc/group file containing entries for standard groups. The most important of these are:
6.1.7 Using Groups Effectively
Effective file permissions are intimately connected to the structure of your system's groups. On many systems, groups are the only method the operating system provides to refer to and operate on arbitrary sets of users. Some sites define the groups on their systems to reflect the organizational divisions of their institution or company: one department becomes one group, for example (assuming a department is a relatively small organizational unit). However, this isn't necessarily what makes the most sense in terms of system security.
Groups should be defined on the basis of the need to share files and, correlatively, the need to protect files from unwanted access. This may involve combining several organizational units into one group or splitting a single organizational unit into several distinct groups. Groups need not mirror "reality" at all if that's not what security considerations call for.
Group divisions are often structured around projects; people who need to work together, using some set of common files and programs, become a group. Users own the files they use most exclusively (or sometimes a group administrator owns all the group's files), common files are protected to allow group access, and all of the group's files can exclude non-group member access without affecting anyone in the group. When someone works on more than one project, then he is made a member of both relevant groups.
When a new project begins, you can create a new group for it and set up some common directories to hold its shared files, protecting them to allow group access (read-execute if members won't need to add or delete files and read-write-execute if they will). Similarly, files will be given appropriate group permissions when they are created based on the access group members will need. New users added to the system for this project can have the new group as their primary group; relevant existing users can be added to it as secondary group members in the group file.
The Unix group mechanism is not a perfect security solution, however. For example, suppose that a user needs access to just one or two files that are owned by a group to which she doesn't belong, and you don't want to make her a member of the second group because it will give her other privileges that you don't want her to have. One solution is to provide a setgid program that allows her to access the needed files; the setuid and setgid access modes are the subject of the next subsection. However, to properly address such a dilemma, you have to go beyond what is offered by the standard Unix group scheme. Access control lists, a mechanism that allows file permissions to be specified on a per-user basis, are the best solution to such problems, and we will consider them in Section 7.4.