Chapter 4 User and Group Administration

As the system administrator of a multiuser system, you are responsible for, among many other tasks, managing and controlling user access to system resources. Because SLES is a multiuser system, this chapter provides you with an understanding of how users and groups are identified, how this information is used to determine access privileges to data and applications, and how you can effectively manage user and group information. The following topics are covered in this chapter:

User and Group IDs

Each user and group in SLES is assigned a unique numeric value because it is much easier for the operating system to deal with numbers than text strings. The number associated with a user is called a user ID (UID) and the number assigned with a group is called a group ID (GID). By default, SUSE LINUX (all versions) assigns UIDs to regular (nonsystem) users starting at 1000, and GID assignments starting at 100.

The Linux standard reserves the UID range from 0 through 99 for the system itself, and the range 100 through 499 for special system users (such as services and applications). To allow room for future expansion, SUSE LINUX thus starts regular user ID values at 1000 (and ends at 60000, by default; the maximum upper limit is 65535). Table 4.1 shows the SLES-created system users, their UIDs, and their primary GIDs.

Table 4.1. SLES Default System User Settings

When you log in to Linux, your active, or current, GID is set to the primary (or default) GID as specified in the user database (such as /etc/passwd), even though you may be a member of multiple groups. The operating system calculates a user’s access permissions to files based on the current GID. You can change your active GID to a new one by using the newgrp command, as follows:

If groupname is not given, the GID is switched back to the primary GID. After you switch to a new group successfully—you must be a member of the group, or be root, to do so—all your actions from then on will have the permissions of that new group. For example, if you create a new file or directory, the group of the new file or directory will be “groupname.”

Upon executing the newgrp command, you remain logged in, the current directory is unchanged, and a new shell is created. Some implementations of newgrp always replace the current shell with a new shell, even if the command terminates with an error (such as when an unknown group was specified). Consider the confusion that may result: Are you in a new shell and need to use the exit command to return to your original shell, or are you still in your original shell where the exit command would terminate your current session? SUSE’s implementation avoids this problem by not creating a new shell should the command fail.

To return to the previous GID and shell, use the exit command and not newgrp; otherwise, you start yet another shell. The following illustrates the effects of the newgrp command:

Linux reserves the GID range from 0 through 10 for system groups. Similar to UIDs, by default, user-created groups start with a GID of 1000, and the GID value can be as high as 60000. Table 4.2 shows the SLES-created system groups and their GIDs.

Table 4.2. SLES Default System Groups and Their GIDs

User and Group Data Files

Linux stores local user and group information in text files in the /etc directory. Traditionally, user information (including passwords) is stored in the /etc/passwd file, and group information is found in the /etc/group file. However, the /etc/passwd file contains information (such as the comment field, which generally contains the user’s full name and the UID of a user) that has to be readable by anyone. At the same time, you don’t want passwords world-readable because this capability gives would-be crackers a good place to start (for example, using a password-cracking tool as discussed in the “BE A CRACKER JACK” section later in this chapter). So the passwords in newer implementations of Linux (such as SLES) are kept in the shadow file (/etc/shadow), which is readable only by root, and everyone’s password is entered into the /etc/passwd file as “x.”

Next, we examine the record structure of each of these three data files.

The /etc/passwd File

Each line in the /etc/passwd file corresponds to an entry for one person, and fields on each line are separated by a colon. The following is a sample record:

The fields, from left to right, are the login name, hashed password, user ID, primary group ID, comment field (officially referred to as the GCOS field), home directory, and default or login shell. The presence of an “x” in the password field indicates that the shadow password file is used; some implementations use an asterisk (*) instead.

As a security measure, some sites populate the GCOS field with the user’s full name and phone numbers but disable the finger daemon (see Chapter 8, “Network Services,” on how to enable/disable various services). Or, TCP/UPD port 79 is blocked at the perimeter firewall so the GCOS information is only available internally but not to an external query. In most cases, only the user’s real name is listed in the GCOS field.

The /etc/passwd file can contain a line (usually the last line in the file) beginning with a plus (+), which means to incorporate entries from Network Information Services (NIS). There are two styles of + entries. A single + means to insert the entire contents of an NIS passwd file at that point:

A line of the form +name means to insert the NIS entry (if any) for that username. If a + entry has a non-null field (such as the default shell), the data in that field overrides what is contained in NIS. In the following example, user ted’s UID, primary GID, GCOS data, and home directory information will come from NIS, but he will be assigned a default shell of /bin/csh regardless of the setting in NIS:

The /etc/passwd file can also contain lines beginning with a minus (-). These entries are used to disallow user entries. There is only one style of - entry; an entry that consists of -name means to disallow any subsequent entry (if any) for name. These entries would disallow the specified users from logging in to the machine. For example,

does not allow user jacques to log in to the local system.

You can also use +@netgroup or -@netgroup to specify entries for all members of the (NIS) network group netgroup into /etc/passwd.

For more information about the /etc/passwd file, use the man 5 passwd command.

The /etc/shadow File

Similar to the /etc/passwd file, each line in the /etc/shadow file is an entry for one person, and the fields are separated by colons. The following is a sample record:

The previous sample record shows the following information for user eric:

You can use chage -l username to examine a user’s password-aging information. The output for eric looks like this:

A nonroot user will be prompted for username’s password for security reasons, even if the user is querying his or her own password-aging data.

The /etc/group File

The /etc/group file contains the names of valid groups and the usernames of their members. This file is owned by root and only root may modify it, but it is world-readable. When a new user is added to /etc/passwd, information on what groups that user is a member of must be added here. Group IDs (GIDs) from the /etc/passwd file are mapped to the group names kept in this file. Similar to users in the /etc/passwd file, the groups are listed one per line. For example,

Each entry consists of four fields separated by a colon:

The preceding sample entry from /etc/group shows the audio group is using shadow passwords; has a GID of 17; and that eric, tasha, and carol are group members.

Similar to etc/passwd, the /etc/group file can contain a line (usually the last line in the file) beginning with a plus (+), which means to incorporate group entries from NIS. A line with a single + means to insert the entire contents of the NIS group file at that point:

A line with +name means to insert the group entry (if any) for name from NIS at that point. If a + entry has a non-null field (such as the group membership), the data in that field overrides what is contained in NIS.

An entry of the form -name means that the group is disallowed. All subsequent entries for that group name, whether in the NIS group file or in the local /etc/group file, are ignored.

For more tinformation on /etc/group, use the man 5 group command.

User Account and Group Management Applications

There are two basic types of applications you can use when managing user accounts and groups on SUSE systems:

While both YaST and the command-line utilities perform essentially the same task, the command-line tools have the advantage of being scriptable and, therefore, more easily automated. On the other hand, YaST provides a wizard-like graphical interface that walks you through the necessary steps.

Table 4.3 describes some of the more common command-line tools used to create and manage users.

Table 4.3. User Management Command-Line Tools

Table 4.4 lists some of the more common command-line tools used to create and manage groups.

Table 4.4. Group Management Command-Line Tools

To learn more about the utilities in Table 4.4, refer to the man page for each (for example, man grpck).

Creating and Editing User Accounts

When you need to create or modify a single user account or a small number of accounts (say, fewer than five), it is usually more convenient to use YaST for the task because of its GUI interface. Otherwise, you may want to consider creating some shell scripts for the task using command-line tools discussed later in this section.

Use the following steps to create a new user account using YaST:

3. From the User and Group Administration screen (see Figure 4.1), select Set Filter and choose the type of user accounts (such as Local Users, System Users, or LDAP Users) you want to manage. A list of current users of the selected type is displayed. You may only see Local Users and System Users available as selections under the Set Filter drop-down list. Additional selections (such as LDAP Users) will be available only after you have configured and started the services on the server.

Figure 4.1. The User and Group Administration module screen in YaST.

4. Select the Add option, and a screen similar to Figure 4.2 is displayed.

Figure 4.2. Adding a new local user.

5. Fill in the user’s name, login ID, and password. Keep in mind that both login names and passwords are case sensitive. Valid passwords can be composed of any of the (7-bit) ASCII characters, including digits and upper- and lowercase letters. However, you should use only printable ASCII characters whose decimal values are between the range of 33 and 126. Spaces (dec. 32) do work if you have a pure Linux/Unix environment but may fail with connections from an X emulator or SSH client from a Windows client. Therefore, you should avoid spaces in passwords. Furthermore, depending on the encryption algorithm (such as DES, which is the default), you may be limited to use only up to eight alphanumeric characters. (See “USE A STRONG PASSWORD-HASHING ALGORITHM” later in this chapter.)

6. Click Password Settings if you want to change the settings (such as password expiration date) for the new user to something other than the defaults. In many cases, the default settings are sufficient and don’t need to be modified.

7. Click Details if you want to change settings such as UID, home directory location, default login shell, and group memberships; the Additional User Information field in this screen corresponds to the GCOS field in /etc/passwd. (Remember that if you plan to run the finger daemon, the information in this field must be in the particular form required by finger; see the earlier “WHAT IS THE GCOS FIELD?” sidebar.) The UIDs are assigned automatically, based on the previously used value, and default settings are read from /etc/default/useradd.

8. Click Create when you are satisfied with the user’s settings.

9. Repeat steps 4 through 8 to create more users. Click Finish when you are done. You must click Finish for the databases to be updated. Otherwise, if you click Abort, any changes made (including new users “added”) will be discarded.

The procedure for updating and deleting a user is similar: Instead of Add, select Edit or Delete after highlighting the desired user.

When you use YaST, you can manage most aspects of the user account within the single application, except you cannot use YaST to enable or disable a user account—you must do this using command-line tools. In addition, because YaST is a menu-driven utility, it does not lend itself to batch creation or modification of user accounts easily. Therefore, we highlight the multistep user-creation process necessary when using the command-line tools.

The following steps illustrate what happens when you issue the command /usr/sbin/useradd -m carol:

A new entry for carol is created in /etc/passwd. The line begins with the username carol, and an “x” is placed in the password field indicating that the system is using shadow passwords. A UID at or above 1000 is created, and the primary GID is set to 100 (group users). The optional GCOS information is left blank. The home directory is created (because of the -m switch) and set as /home/carol, and the default shell is set to /bin/bash as specified by /etc/default/useradd.

A new entry for carol is created in /etc/shadow. The line begins with the username carol, and an exclamation point (!) is placed in the password field, which locks the account. The related password policy (such as expiration date) is set according to the values found in /etc/default/useradd.

Group memberships in /etc/group are updated to include carol in the appropriate groups, such as dialout, uucp, video, and audio. User carol is not added to the group users because it is her primary group.

A directory for carol is created in the /home directory. This directory’s ownership is set to user carol and group users. Full privileges (read, write, and execute) are granted to carol, while group and others have only read and execute privileges.

The files (including subdirectories) within the /etc/skel directory (which contain default user settings, such as .bashrc) are copied into the new /home/carol directory. If useradd is used without the -m option, the home directory is not created; thus, files from /etc/skel are not copied. You can override settings in /etc/default/useradd using additional command-line switches, such as -g and -d. Refer to man useradd for more information.

At this point, a locked account called carol exists on the system. To activate it, you must next assign a password to the account using the passwd command and, optionally, set password-aging guidelines.

It is also possible to configure the account so that during the first login, the user is asked to change his or her password. To configure a user account in this manner, follow these steps:

The UMASK directive in /etc/login.defs is used by useradd and YaST to set the proper file permissions on the home directory. Refer to Chapter 6 for information about file ownership and permissions. The USERDEL_PRECMD and USERDEL_POSTCMD directives point to two templates that you can customize for your particular needs. For instance, you may want to copy the user’s home directory elsewhere before you delete the user ID. The default script for the USERDEL_PRECMD directive deletes any cron jobs belonging to the user, whereas the default USERDEL_POSTCMD does nothing.

Where redundancy exists between /etc/login.defs and /etc/default/useradd, the settings in /etc/login.defs take precedence.

Creating and Editing Groups

The process for managing groups is similar to that for users. Rather than listing many of the same steps again, we’ve listed the salient differences here instead:

There are three commonly used command-line utilities for managing groups:

You will not find a /etc/gshadow file on SLES 9 and later systems because it is no longer used.

Security Considerations

The first step in securing any operating system is to secure the user and group accounts. This includes, but is not limited to, the following:

These steps are discussed in the following sections. Other precautions, such as securing a user’s working environment, handling filesystem security, preventing and detecting intruders, as well as system hardening are discussed in later chapters in this book

Using Strong Passwords

Like having good and secure locks on your house, you want users to pick passwords that are difficult to guess yet easy enough to remember so the users will not write down their passwords for the world to find. Difficult-to-guess passwords means they should not be associated with the user personally, such as the name of his or her spouse, names of children, pets, or the user’s address. Strong passwords should also not include dictionary words. Many password-cracking programs make use of word lists to brute-force crack passwords. Many of these programs are freely available over the Internet; two of the most popular password-crackers are Crack and John the Ripper. We will discuss how you can use John the Ripper to detect weak passwords on your system in Chapter 11.

One way to select a difficult-to-guess password is to use a randomly selected string of characters, such as i2#yA9%3r. This is not a word found in any dictionary, nor is it remotely connected to a user. Unfortunately, your user probably wouldn’t be able to remember such a password. The likely result is that the user will write it down on a sticky note and paste it underneath his or her keyboard!

A better way to select a strong password is to use a short phrase (commonly referred to as a passphrase) such as I missed hockey! Alternatively, you can derive a password from a long sentence such as The Adventures of Buckaroo Banzai across the Eighth Dimension! One derivation is to simply take the first letter from each word, except for the word Eighth, which is replaced by the number 8, and you get TaoBBat8D. Or you can take the second letter of each word, except again for the word Eighth, and you get hdfuach8i. As you can see, you can use many variations to come up with difficult-to-guess but rather easy-to-remember passwords.

The standard industry recommendations on selecting strong passwords and enforcing password security are summarized in the following sections.

PROTECT YOUR PASSWORDS

The first rule of password security is that you don’t ever write down your password; memorize it instead. In particular, don’t write it down and leave it somewhere that is publicly or easily accessible by others, and don’t place it in an unencrypted file! If you can’t memorize it, you didn’t choose a good password. If you must write it down, keep it on your person at all times!

If you have access to different systems and a centralized authentication mechanism (such as NIS or LDAP) is not used, use unrelated passwords on these machines. This also applies to your access to systems controlled by different organizations: You don’t know how well they protect their systems and don’t want to help any bad guys to get into your servers using information hacked from those other systems.

Don’t give or share your password, in particular to someone claiming to be from computer support or a vendor, especially over the phone! Often, a hacker uses deception or misdirection to obtain information from an unsuspecting user—especially a new user. The hacker often pretends to be someone in authority, such as someone from IT Security or a vendor’s customer support group that needs to verify a user’s identity. Consider the following telephone conversation:

This method is referred to as social engineering. The hacker simply carries out a seemingly innocent conversation with the victim in a social setting and obtains the necessary information without having to spend days trying to crack a single MD5- or Blowfish-hashed password!

Don’t let anyone watch you enter your password and don’t enter your password into a computer you do not trust. If the password is needed only for a limited time, change it periodically. When it comes to safeguarding your password, the golden rule is practice perseverance and vigilance.

CHOOSE HARD-TO-GUESS PASSWORDS

A strong password should be something you would not find in a dictionary (in any language or jargon). You shouldn’t use a name (including that of a spouse, parent, child, pet, and so on) or any variation of your personal or login name. Don’t use publicly accessible information about you (such as your phone number, car license plate, or employee number) or your environment (such as office address) as part of your password. Don’t use a birthday or a simple pattern (such as spelling the username backward, following the name with a digit, or preceding the name with a digit).

A good, hard-to-guess password consists of a mixture of upper- and lowercase letters as well as digits or punctuation. When choosing a new password, make sure it’s unrelated to any previous passwords (such as by adding a digit to an old password). Use long passwords (say, eight characters or more). You might use a word pair with punctuation inserted (such as greAT:@Book), a passphrase, or selected letters of each word in a long sentence, as discussed previously.

BUTTON DOWN THE HATCHES!

You should never, ever, allow an account without a password. Such an account is an open invitation begging some bad guy to compromise your system. Lock all unused accounts—for users who are away for an extended period of time or users who have left your organization but you need to retain their environments—using the passwd -l command. You will also find many of the system accounts to have an invalid password assigned (a single * or ! in the password field in /etc/shadow). These accounts exist to allow programs to be run as the UID associated with that account; they are not direct login accounts. If you ever need to create such an account, ensure you disable its login access.

USE PASSWORD AGING

No matter how hard a password is to guess, if it has been used for an extended period of time, someone is going to figure it out. It is not uncommon for users to brag with each other about how secure or how clever their passwords are: “I used all my three children’s middle names. How’s that for a tough password?” “You know the color that I really, really hate?” or “Hey, I used my wife’s favorite Italian dish as my password. Try to guess that!”

Given enough talk, and some luck, a bad guy may just figure out what the password is. Therefore, it is a good idea to force the users to periodically change their passwords. Password aging may be implemented on a system-wide basis or on a per-user basis. Password-aging policy in Linux is controlled through the shadow password file and is configured automatically by SLES during installation.

BE A CRACKER JACK

Use a password-cracker yourself to audit for weak passwords. SUSE LINUX implements Pluggable Authentication Module (PAM) by default to provide flexible user authentication. One of the side benefits of PAM is its ability to help enforce strong passwords (through the pam_pwcheck module, for instance). (You can find more details about PAM in Chapter 5, “User Environment Management and Security.”) There is always a possibility that another system administrator assigned a weak password without realizing it. To find out, you should periodically use a password-cracker, such as John the Ripper, to self-audit and see whether any weak passwords are reported.

USE A STRONG PASSWORD-HASHING ALGORITHM

The previous recommendations of using passphrases and long passwords are fine if the password-hashing algorithm you use supports long strings. By default, SLES 9 (and many other Linux distributions) uses a DES-based algorithm, which supports passwords up to eight characters in length; any string longer than eight characters is truncated to eight characters in size. Fortunately, SUSE ships with the option of encrypting passwords with the stronger MD5 hash algorithm or with Blowfish. (For more information on the MD5 hash algorithm, consult RFC 1321; see http://www.schneier.com/blowfish.html for more information about the Blowfish encryption algorithm.) Although MD5 and Blowfish passwords do not eliminate the threat of password cracking, they do make cracking your passwords much more difficult.

If you didn’t change the password-hashing algorithm from DES to MD5 or Blowfish during install, you can easily change it at a later time. This is easily done using YaST because it will make changes to all the related configuration files for you (such as /etc/security/pam_unix2.conf and /etc/security/pam_pwcheck.conf). You can make the change either via the User and Group Administration module or the Local Security Configuration module as follows:

Figure 4.4. Changing the password-hashing method.

From the YaST Control Center, select Security and Users, Security Settings to launch the Local Security Configuration module. If the Current Security Setting is one of Level 1 through Level 3, click Details. If the selection is Custom Settings, click Next. The first screen is Password Settings (see Figure 4.5). From the Password Encryption Method drop-down list, select the desired method. Make any other changes if desired. Click Next until the Miscellaneous Settings screen is displayed. Click Finish for the new change(s) to take effect. (From a terminal session, you can launch the Local Security Configuration module directly using yast security or yast2 security.)

Figure 4.5. Changing the password-hashing method via the Local Security Configuration module.

You can determine what hashing algorithm was used for a given password hash by examining /etc/shadow—another reason why this file is accessible by root only because you don’t want to give any hackers hints on what hashing algorithm you are using:

Each of the DES, MD5, and Blowfish algorithms has its pros and cons, and you should give them some careful thought before picking one. For instance, the Linux (and Unix) implementation of the DES hashing method limits the password to only eight characters, but because all versions of Linux/Unix and most other Unix-like operating systems support it, it is a good choice for cross-platform compatibility. On the other hand, MD5 and Blowfish allow for much longer passwords (127 characters for MD5 and 72 characters for Blowfish), but the algorithms are computational-intensive. So if you have an underpowered server that needs to perform many user authentications per second (such as an LDAP authentication server), performance will suffer. There are also some networking protocols that do not play well with passwords longer than eight characters. For example, only the first eight characters are significant in NIS+ passwords because the underlying secure-RPC protocol uses DES.

Consider the following suggestions when choosing a password-hashing algorithm for your system:

In most cases, MD5 provides the best balance between performance and security.

Auditing Default Accounts

As mentioned earlier, a number of system accounts exist to allow programs to be run as the UID associated with that account; they are not direct login accounts. FTP, named (for DNS), mail, and news are some examples of such system accounts. Make sure such accounts are prevented from a terminal login by setting their shell to /bin/false or similar.

If the services for these accounts are not in use, uninstall them and remove the accounts—or at the very least, disable unused services (see Chapter 8 for more information). Periodically, you should check the contents of /etc/passwd and /etc/shadow to ensure that the removed system accounts didn’t “spontaneously resurrect” themselves or new system accounts were not added without your knowledge, and nonlogin system accounts don’t “suddenly” get assigned valid password hashes and shells.

The Root Account

The root account is the key to your entire server kingdom (and to your entire network if the server in question serves as the central authentication server). Nothing is more important than the password to the root account in the Linux/Unix world. For this reason, you will not want to make your root password known to anyone else but yourself. Well, this is often easier said than done.

As you may already have found out, many of the administrative tasks, such as resetting a user’s forgotten password, changing system configuration, and so on, require you to be root. If you’re the lone ranger who looks after the system(s) at your organization, keeping the root password safe is relatively easy: Follow the recommendations given earlier in this chapter about selecting strong passwords, change it often, never write it down, and so on. However, it is not uncommon in a company for system administration tasks to be shared by two or more people. In such cases, how do you safeguard the root password effectively? The more people who know it, the higher the likelihood it will be leaked to someone who shouldn’t know about it!

There are a number of ways to address the multiple administrator requirements, and we discuss two of them here:

User in Too Many Groups?

Linux and most other recent Unix systems support at least 32 groups per user. However, because the NFS protocol supports only 16 groups, most of them (SUSE included) have imposed a soft limit of 16 groups per user. There are very rarely circumstances that require more than 16 groups, but it is usually possible to use more if the system will not be exporting or using NFS-mounted filesystems; NFS has a hard-coded limit of 16 groups in its underlying RPC protocol. The first 16 groups are passed to the NFS server for permission checking, while the others are ignored. In other words, a user might appear to belong to a group, but if the 16-group limit is exceeded, the user might not have the access privileges of that group.

Summary

This chapter provided information on how users and groups are identified in Linux and how you can effectively manage user and group information using YaST and command-line tools. The following topics were covered in this chapter:

The next chapter will provide you with information and tips on how best to secure your users’ working environment. For instance, you can restrict users to be able to log in using only certain terminal consoles and apply disk quotes so the server does not run out of disk space, resulting in what is sometimes known as “self denial of service” (SDOS).