 | Chapter 4 |  |
| Chapter 4 | |
In Chapter 3, Users and Passwords, we explained that every UNIX user has a user name to define an account. In this chapter, we'll describe how the operating system views users, and we'll discuss how accounts and groups are used to define access privileges for users. We will also discuss how you may assume the identity of another user or group so as to temporarily use their access rights.
Although every UNIX user has a username of up to eight characters long, inside the computer UNIX represents each user by a single number: the user identifier (UID). Usually, the UNIX system administrator gives every user on the computer a different UID.
UNIX also uses special usernames for a variety of system functions. As with usernames associated with human users, system usernames usually have their own UIDS as well. Here are some common "users" on various versions of UNIX:
root, the superuser, which performs accounting and low-level system functions.
daemon or sys, which handles some aspects of the network. This username is also associated with other utility systems, such as the print spoolers, on some versions of UNIX.
agent, which handles aspects of electronic mail. On many systems, agent has the same UID as daemon.
guest, which is used for site visitors to access the system.
lp, which is used for the printer system.[1]
[1] lp stands for line printer, although these days most people seem to be using laser printers.
nobody, which is a user that owns no files and is sometimes used as a default user for unprivileged operations.
Here is an example of an /etc/passwd file containing these system users:
root:zPDeHbougaPpA:0:1:Operator:/:/bin/ksh nobody:*:60001:60001::/tmp: agent:*:1:1::/tmp: daemon:*:1:1::/tmp: ftp:*:3:3:FTP User:/usr/spool/ftp: uucp:*:4:4::/usr/spool/uucppublic:/usr/lib/uucp/uucico news:*:6:6::/usr/spool/news:/bin/csh
Notice that most of these accounts do not have "people names," and that all except root have a password field of *. This prevents people from logging into these accounts from the UNIX login: prompt, as we'll discuss later.[2]
[2] This does not prevent people from logging in if there are trusted hosts/users on that account; we'll describe these later in the book.
NOTE: There is nothing magical about these particular account names. All UNIX privileges are determined by the UID (and sometimes the group ID, or GID), and not directly by the account name. Thus, an account with name root and UID 1005 would have no special privileges, but an account named mortimer with UID 0 would be a superuser. In general, you should avoid creating users with a UID of 0 other than root, and you should avoid using the name root for a regular user account. In this book, we will use the terms "root" and "superuser" interchangeably.
UIDs are historically unsigned 16-bit integers, which means they can range from 0 to 65535. UIDs between 0 and 9 are typically used for system functions; UIDs for humans usually begin at 20 or 100. Some versions of UNIX are beginning to support 32-bit UIDs. In a few older versions of UNIX, UIDs are signed 16-bit integers, usually ranging from -32768 to 32767.
UNIX keeps the mapping between usernames and UIDs in the file /etc/passwd. Each user's UID is stored in the field after the one containing the user's encrypted password. For example, consider the sample /etc/passwd entry presented in Chapter 3:
rachel:eH5/.mj7NB3dx:181:100:Rachel Cohen:/u/rachel:/bin/ksh
In this example, Rachel's username is rachel and her UID is 181.
The UID is the actual information that the operating system uses to identify the user; usernames are provided merely as a convenience for humans. If two users are assigned the same UID, UNIX views them as the same user, even if they have different usernames and passwords. Two users with the same UID can freely read and delete each other's files and can kill each other's programs. Giving two users the same UID is almost always a bad idea; we'll discuss a few exceptions in the next section.
There are two exceptions when having multiple usernames with the same UID is sensible. The first is for logins used for the UUCP system. In this case, it is desirable to have multiple UUCP logins with different passwords and usernames, but all with the same UID. This allows you to track logins from separate sites, but still allows each of them access to the shared files. Ways of securing the UUCP system are described in detail in Chapter 15, UUCP.
The second exception to the rule about only one username per UID is when you have multiple people with access to a system account, including the superuser account, and you want to track their activities via the audit trail. By creating separate usernames with the same UID, and giving the users access to only one of these identities, you can do some monitoring of usage. You can also disable access for one person without disabling it for all.
As an example, consider the case where you may have three people helping administer your Usenet news software and files. The password file entry for news is duplicated in the /etc/passwd file as follows:
root:zPDeHbougaPpA:0:1:Operator:/:/bin/ksh nobody:*:60001:60001::/tmp: daemon:*:1:1::/tmp: ftp:*:3:3:FTP User:/usr/spool/ftp: news:*:6:6::/usr/spool/news:/bin/csh newsa:Wx3uoih3B.Aee:6:6:News co-admin Sabrina:/usr/spool/news:/bin/csh newsb:ABll2qmPi/fty:6:6:News co-admin Rachel:/usr/spool/news:/bin/sh newsc:x/qnr4sa70uQz:6:6:News co-admin Fred:/usr/spool/news:/bin/ksh
Each of the three helpers has a unique password, so they can be shut out of the news account, if necessary, without denying access to the others. Also, the activities of each can now be tracked if the audit mechanisms record the account name instead of the UID (most do, as we describe in Chapter 10, Auditing and Logging). Because the first entry in the passwd file for UID 6 has the account name news, any listing of file ownership will show files belonging to user news, not to newsb or one of the other users. Also note that each user can pick his or her own command interpreter (shell) without inflicting that choice on the others.
This approach should only be used for system-level accounts, not for personal accounts. Furthermore, you should institute rules in your organizations that require users (Sabrina, Rachel, and Fred) to log in to their own personal accounts first, then su to their news maintenance accounts - this provides another level of accountability and identity verification. (See the discussion of su later in this chapter.) Unfortunately, in most versions of UNIX, there is no way to enforce this requirement, except by preventing root from logging on to particular devices.
Every UNIX user belongs to one or more groups. Like user accounts, groups have both a groupname and a group identification number (GID). GID values are also historically 16-bit integers.
As the name implies, UNIX groups are used to group users together. As with usernames, groupnames and numbers are assigned by the system administrator when each user's account is created. Groups can be used by the system administrator to designate sets of users who are allowed to read, write, and/or execute specific files, directories, or devices.
Each user belongs to a primary group that is stored in the /etc/passwd file. The GID of the user's primary group follows the user's UID. Consider, again, our /etc/passwd example:
rachel:eH5/.mj7NB3dx:181:100:Rachel Cohen:/u/rachel:/bin/ksh
In this example, Rachel's primary GID is 100.
Groups provide a handy mechanism for treating a number of users in a certain way. For example, you might want to set up a group for a team of students working on a project so that students in the group, but nobody else, can read and modify the team's files.
Groups can also be used to restrict access to sensitive information or specially licensed applications to a particular set of users: for example, many UNIX computers are set up so that only users who belong to the kmem group can examine the operating system's kernel memory. The ingres group is commonly used to allow only registered users to execute the commercial Ingres database program. And a sources group might be limited to people who have signed nondisclosure forms so as to be able to view the source code for some software.
NOTE: Some special versions of UNIX support MAC (Mandatory Access Controls), which have controls based on data labeling instead of, or in addition to, the traditional UNIX DAC (Discretionary Access Controls). MAC-based systems do not use traditional UNIX groups. Instead, the GID values and the /etc/group file may be used to specify security access control labeling or to point to capability lists. If you are using one of these systems, you should consult the vendor documentation to ascertain what the actual format and use of these values might be.
The /etc/group file contains the database that lists every group on your computer and its corresponding GID. Its format is similar to the format used by the /etc/passwd file.[3]
[3] As with the password file, if your site is running NIS, NIS+, NetInfo, or DCE, the /etc/group file may be incomplete or missing. See the discussion in "The /etc/passwd File and Network Databases" in Chapter 3.
Here is a sample /etc/group file that defines five groups: wheel, uucp, vision, startrek, and users:
wheel:*:0:root,rachel uucp:*:10:uucp users:*:100: vision:*:101:keith,arlin,janice startrek:*:102:janice,karen,arlin
The first line of this file defines the wheel group. The fields are explained in Table 4.1.
Field Contents | Description |
|---|---|
wheel | The group name |
* | The group's "password" (described below) |
0 | The group's GID |
root, rachel | The list of the users who are in the group |
.
Most versions of UNIX use the wheel group[4] as the list of all of the computer's system administrators (in this case, rachel and the root user are the only members). The second line of this file defines the uucp group. The only member in the uucp group is the uucp user. The third line defines the users group; the users group does not explicitly list any users; each user on this particular system is a member of the users group by virtue of their individual entries in the /etc/passwd file.
[4] Not all versions of UNIX call this group wheel; this is group 0, regardless of what it is named.
The remaining two lines define two groups of users. The vision group includes the users keith, arlin and janice. The startrek group contains the users janice, karen, and arlin. Notice that the order in which the usernames are listed on each line is not important. (This group is depicted graphically in Figure 4.1.)
Remember, the users mentioned in the /etc/group file are in these groups in addition to the groups mentioned as their primary groups in the file /etc/passwd. For example, Rachel is in the users group even though she does not appear in that group in the file /etc/group because her primary group number is 100. On some versions of UNIX, you can issue the groups command or the id command to list which groups you are currently in.
Groups are handled differently by versions of System V UNIX before Release 4 and by Berkeley UNIX; SVR4 incorporates the semantics of BSD groups.
NOTE: It is not necessary for there to be an entry in the /etc/group file for a group to exist! As with UIDs and account names, UNIX actually uses only the integer part of the GID for all settings and permissions. The name in the /etc/group file is simply a convenience for the users - a means of associating a mnemonic with the GID value.
Figure 4.1 illustrates how users can be included in multiple groups.
Under versions of AT&T UNIX before SVR4, a user can occupy only a single group at a time. To change your current group, you must use the newgrp command. The newgrp command takes a single argument: the name of the group that you're attempting to change into. If the newgrp command succeeds, it execs a shell that has a different GID, but the same UID:
$ newgrp news $
This is similar to the su command used to change UID.
Usually, you'll want to change into only these groups in which you're already a member; that is, groups that have your username mentioned on their line in the /etc/group file. However, the newgrp command also allows you to change into a group of which you're not normally a member. For this purpose, UNIX uses the group password field of the /etc/group file. If you try to change into a group of which you're not a member, the newgrp command will prompt you for that group's password. If the password you type agrees with the password for the group stored in the /etc/group file, the newgrp command temporarily puts you into the group by spawning a subshell with that group:
$ newgrp fiction password: rates34 $
You're now free to exercise all of the rights and privileges of the fiction group.
The password in the /etc/group file is interpreted exactly like the passwords in the /etc/passwd file, including salts (described in Chapter 8, Defending Your Accounts). However, most systems do not have a program to install or change the passwords in this file. To set a group password, you must first assign it to a user with the passwd command, then use a text editor to copy the encrypted password out of the /etc/passwd file and into the /etc/group file. Alternatively, you can encode the password using the /usr/lib/makekey program (if present) and edit the result into the /etc/group file in the appropriate place.[5]
[5] We suspect that passwords have seldom been used in the group file. Otherwise, by now someone would have developed an easier, one-step method of updating the passwords. UNIX gurus tend to write tools for anything they have to do more than twice and that require more than a few simple steps. Updating passwords in the group file is an obvious candidate, but a corresponding tool has not been developed. Ergo, the operation must not be common.
NOTE: Some versions of UNIX, such as AIX, do not support group passwords.
One of the many enhancements that the Berkeley group made to the UNIX operating system was to allow users to reside in more than one group at a time. When a user logs in to a Berkeley UNIX system, the program /bin/login scans the entire /etc/group file and places the user into all of the groups in which that user is listed.[6] The user is also placed in the primary group listed in the user's /etc/passwd file entry. When the system needs to determine access rights to something based on the user's membership in a group, it checks all the current groups for the user to determine if that access should be granted (or denied).
[6] If you are on a system that uses NIS, NIS+ or some other system for managing user accounts throughout a network, these network databases will be referenced as well. For more information, see Chapter 19, RPC, NIS, NIS+, and Kerberos.
Thus, Berkeley and SVR4 UNIX have no obvious need for the newgrp command - indeed, many of the versions do not include it. However, there may be a need for it in some cases. If you have a group entry with no users listed but a valid password field, you might want to have some users run the newgrp program to enter that group. This action will be logged in the audit files, and can be used for accounting or activity tracking. However, situations where you might want to use this are likely to be rare. Note, however, that some systems, including AIX, do not support use of a password in the /etc/group file, although they may allow use of the newgrp command to change primary group.
|  | |
| 3.8 Summary |  | 4.2 Special Usernames |