Red Hat Fedora 4 Unleashed

2017-07-07 02:10:07

< Day Day Up >

Passwords are an integral part of Linux security, and they are the most visible part to the user. In this section, you will learn how to establish a minimal password policy for your system, where the passwords are stored, and how to manage passwords for your users.

System Password Policy

An effective password policy is a fundamental part of a good system administration plan. The policy should cover:

Allowed and forbidden passwords

The frequency of mandated password changes

The retrieval or replacement of lost or forgotten passwords

Password handling by users

The Password File

The password file is /etc/passwd, and it is the database file for all users on the system. The format of each line is as follows:

username:password:uid:gid:gecos:homedir:shell

The fields are self-explanatory except for the GECOS field. This field is for miscellaneous information about the user, such as the users' full name, his office location, office and home phone numbers, and possibly a brief text message. For security and privacy reasons, this field is little used nowadays, but the system administrator should be aware of its existence since the GECOS field is used by traditional Unix programs such as finger and mail. For that reason, it is commonly referred to as the finger information field. The data in this field will be comma delimited; the GECOS field can be changed with the cgfn (change finger) command.

Note that a colon separates all fields in the /etc/passwd file. If no information is available for a field, that field is empty, but all the colons remain.

If an asterisk appears in the password field, that user will not be permitted to log on. Why does this feature exist? So a user can be easily disabled and (possibly) reinstated later without having to be created all over again. The system administrator manually edits this field, which is the traditional Unix way of accomplishing this task. Fedora provides improved functionality with the passwd -l command mentioned earlier.

Several services run as pseudo-users, usually with root permissions. These are the system, or logical, users mentioned previously. You would not want these accounts available for general login for security reasons, so they are assigned /sbin/nologin as their shell, which prohibits any logins from those "users."

A list of /etc/passwd reveals

# cat /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/etc/news: uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin dbus:x:81:81:System message bus:/:/sbin/nologin vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin nscd:x:28:28:NSCD Daemon:/:/sbin/nologin rpm:x:37:37::/var/lib/rpm:/sbin/nologin haldaemon:x:68:68:HAL daemon:/:/sbin/nologin netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin pcap:x:77:77::/var/arpwatch:/sbin/nologin apache:x:48:48:Apache:/var/www:/sbin/nologin xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin ntp:x:38:38::/etc/ntp:/sbin/nologin gdm:x:42:42::/var/gdm:/sbin/nologin named:x:25:25:Named:/var/named:/sbin/nologin dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin postfix:x:89:89::/var/spool/postfix:/sbin/nologin andrew:x:500:500:Andrew Hudson:/home/andrew:/bin/bash

Note that all the password fields do not show a password, but contain an x because they are shadow passwords, a useful security enhancement to Linux, discussed in the following section.

Shadow Passwords

It is considered a security risk to keep any password in /etc/passwd because anyone with read access can run a cracking program on the file and obtain the passwords with little trouble. To avoid this risk, shadow passwords are used so that only an x appears in the password field of /etc/passwd; the real passwords are kept in /etc/shadow, a file that can only be read by the sysadmin (and PAM, the Pluggable Authentication Modules authentication manager; see the "PAM Explained" sidebar for an explanation of PAM).

Special versions of the traditional password and login programs must be used to enable shadow passwords. Shadow passwords are automatically enabled during the installation phase of the operating system on Fedora systems.

Let's examine a listing of the shadow companion to /etc/passwd, the /etc/shadow file:

# cat /etc/shadow root:$1$QmG67w3D$B7/xVSB3sehbK8.DL4y.w0:12782:0:99999:7::: bin:*:12782:0:99999:7::: daemon:*:12782:0:99999:7::: adm:*:12782:0:99999:7::: lp:*:12782:0:99999:7::: sync:*:12782:0:99999:7::: shutdown:*:12782:0:99999:7::: halt:*:12782:0:99999:7::: mail:*:12782:0:99999:7::: news:*:12782:0:99999:7::: uucp:*:12782:0:99999:7::: operator:*:12782:0:99999:7::: games:*:12782:0:99999:7::: gopher:*:12782:0:99999:7::: ftp:*:12782:0:99999:7::: nobody:*:12782:0:99999:7::: dbus:!!:12782:0:99999:7::: vcsa:!!:12782:0:99999:7::: nscd:!!:12782:0:99999:7::: rpm:!!:12782:0:99999:7::: haldaemon:!!:12782:0:99999:7::: netdump:!!:12782:0:99999:7::: sshd:!!:12782:0:99999:7::: rpc:!!:12782:0:99999:7::: rpcuser:!!:12782:0:99999:7::: nfsnobody:!!:12782:0:99999:7::: mailnull:!!:12782:0:99999:7::: smmsp:!!:12782:0:99999:7::: pcap:!!:12782:0:99999:7::: apache:!!:12782:0:99999:7::: xfs:!!:12782:0:99999:7::: ntp:!!:12782:0:99999:7::: gdm:!!:12782:0:99999:7::: named:!!:12782:0:99999:7::: dovecot:!!:12782:0:99999:7::: postfix:!!:12782:0:99999:7::: andrew:$1$TIkBJRsW$444QX2igYBlUj.l3I9cyA.:12782:0:99999:7:::

The fields are separated by colons and are, in order:

The user's login name.

The encrypted password for the user.

The number of days since Jan 1, 1970 that the password was last changed. This date is know in Unix circles as the "epoch." Just so you know, the billionth second since the epoch occurred was in September 2001; that was the Unix version of Y2K; not much happened because of it.

The number of days before the password can be changed (prevents changing a password and then changing it back to the old password right away a dangerous security practice).

The number of days after which the password must be changed. This can be set to force the change of a newly issued password known to the system administrator.

The number of days before the password expiration that the user is warned it will expire.

The number of days after the password expires that the account is disabled (for security).

The number of days since Jan 1, 1970 that account has been disabled.

The final field is a "reserved" field and is not currently allocated for any use.

Note that password expiration dates and warnings are disabled by default in Fedora. These features are not used on home systems and usually not used for small offices. It is the sysadmin's responsibility to establish and enforce password expiration policies.

The permissions on the /etc/shadow file should be set so that it is not writable or readable by regular users: The permissions should be 600.

PAM Explained

Pluggable Authentication Modules (PAM) is a system of libraries that handle the tasks of authentication on your computer. It uses four management groups: account management, authentication management, password management, and session management. This allows the system administrator to choose how individual applications will authenticate users. Fedora has preinstalled and preconfigured all the necessary PAM files for you.

The configuration files in Fedora Core are found in /etc/pam.d. These files are named for the service they control, and the format is as follows:

type control module-path module-arguments

The type field is the management group that the rule corresponds to. The control field tells PAM what to do if authentication fails. The final two items deal with the PAM module used and any arguments it needs. Programs that use PAM typically come packaged with appropriate entries for the /etc/pam.d directory. To achieve greater security, the system administrator can modify the default entries. Misconfiguration can have unpredictable results, so back up the configuration files before you modify them. The defaults provided by Fedora Core are adequate for home and small office users.

As an example of a PAM configuration file with the formatted entries as described previously is shown next. Here are the contents of /etc/pam.d/system-config-users:

#%PAM-1.0 auth sufficient /lib/security/pam_rootok.so auth required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_permit.so session optional /lib/security/pam_xauth.so account required /lib/security/pam_permit.so

Amusingly, even the PAM documents state that you do not really need (or want) to know a lot about PAM to use it effectively.

You will likely only need the PAM system administrators guide. Look under the /usr/share/doc/pam* directory for additional documents in PostScript, text, and HTML formats.

If you configure you system to use LDAP or kerberos authentication during install and are unable to log on to the machine using the local root account, be aware that there is a known bug in the /etc/pam.d/system-auth file. As a temporary fix, change the line that reads

account required /lib/security/$ISA/pam_unix.so

account sufficient /lib/security/$ISA/pam_unix.so

The underlying problem appears to be a flaw in the way that PAM handles intervals for requests for authorization. This issue has existed since Red Hat 7.3 and does not appear to be fixed in Fedora Core.

Managing Password Security for Users

Selecting appropriate user passwords is always an exercise in trade-offs. A password such as password (don't laugh, it has been used too often before in the real world) is just too easy to guess by an intruder as are simple words or number combinations (a street address, for example). A security auditor for one of my former employers would take the cover sheet from the employees' personnel file (which contained the usual personal information of name, address, birth date, and so on) and would then attempt to log on to a terminal with passwords constructed from that information and often succeeded in logging on.

On the other hand, a password such as 2a56u'"F($84u&#^Hiu44Ik%$([#EJD is sure to present great difficulty to an intruder (or an auditor). However, that password is so difficult to remember that it would be likely that the password owner would write that password down and tape it next to her keyboard. I worked for a business in which the safe combination was written on the ceiling tile over the safe; the manager could not remember it and was told he should not keep it on a piece of paper in his wallet. This is but one of many examples of poor security in the field.

The sysadmin has control, with settings in the /etc/shadow file, over how often the password must be changed. The settings can be changed using a text editor, the change command, or a configuration tool such as Fedora's User Manager, as shown in Figure 13.1. Click on the Password Info tab under that particular user's Properties to set individual password policies.

Changing Passwords in a Batch

On a large system, there might be times when a large number of users and their passwords need some attention. The superuser can change passwords in a batch by using the chpasswd command, which accepts input as a name/password pair per line in the following form:

# chpasswd username:password

Passwords can be changed en masse by redirecting a list of name and password pairs to the command. An appropriate shell script can be constructed with the information gleaned from Chapter 14.

However, Fedora also provides the newusers command to add users in a batch from a text file. This command also allows a user to be added to a group, and a new directory can be added for the user as well.