3.3. User Registration

In this section, I will consider the process of registering users in the system. This should help you better understand the security system used in Linux during the authorization process.

You already know, from Section 3.2 : The init program loads several getty virtual consoles. Any user attempting to exploit any of these virtual consoles has to undergo the authorization procedure, for which he or she must provide the login (user name ). The login entered is passed to the login program, which in turn requests the password.

The login program compares the user name entered with the list of names in the /etc/passwd file and the password with the corresponding entry in the /etc/shadow file. The passwords in the file are encrypted. The password entered by the user is also encrypted, and the result is compared with the encrypted password stored in the /etc/shadow file for the user name specified.

Why is the verification process so complex? The reason for this is that all passwords stored in the /etc/shadow file are encrypted with an irreversible algorithm (most often, the MD5 algorithm is used). This means that the plaintext password cannot be obtained from the encrypted password using mathematical means; it can only be picked using the enumerative or the dictionary methods . There are many simple programs that do this. The simpler and shorter the password is, the faster it is picked. If the password is complex and more than 8 characters long (or, even better, more than 16 characters long), picking it may take too much time and discourage the hacker.

If the user identification is successful, the login program executes all automatically-loaded scripts and launches the shell (the command line) that will be used to interact with the system. If the verification fails, the system returns control to the getty console, which starts the login process anew.

Consequently, unless the user passes the login authorization, access to the command shell will be denied and only the getty console will be available, which can only ask for the user's name and pass this name to the login program.

Next I will consider some problems that may arise when logging into the system and how these problems can be solved .

3.3.1. Shadow Passwords

In older Linux versions, the user list and the passwords were stored in the /etc/passwd file. This was a security risk; all users had to have access to this file because many innocent programs require user names. For example, when the ls command (view the contents of the current folder) is executed, it needs to have access to the user list to obtain the names of the file owners . Because the file can be read by any user, the encrypted passwords contained in it can also be read by any user. This makes it possible for a user to pick any of the passwords by the enumeration or the dictionary method.

To protect the passwords, all modern Linux versions store them in the /etc/shadow file, to which only the administrator has access. The /etc/passwd file remains accessible to anyone , but now no passwords are stored in it. Take a look at the /etc/passwd file's structure. For an example, I took three first lines from my file:

 root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x: 2:2:daemon:/sbin:/sbin/nologin

Each entry contains seven items of user information delimited by colons. Their functions, in order of their appearance, are as follows :

User name The name typed when logging into the system.
Password The encrypted password. If shadow passwords are being used, this field contains an x character
User identifier (UID) The unique numerical UID corresponding to the given user name.
Group identifier (GID) The unique numerical GID.
User information Optional information such as the user's full name, address, and so on.
Home directory The absolute path to the directory, in which the user starts working when entering the system.
Shell The shell (a command interpreter) that will execute the user's commands. If the user is not supposed to have a command interpreter, the /sbin/nologin file is specified.

Now, examine the entry for the root user. The first parameter is the user's name, which is, of course, root . The password is not shown in the file. It is represented by the x (or !! ) character, the password itself being stored in the corresponding entry of the /etc/shadow file.

The next two parameters are the unique UID and the unique GID. There can be no two entries with the same UID in the file. The system uses the GID to determine the group, to which the user belongs, and define the rights granted to this group and, accordingly , to the user.

The user information parameter can contain any data; it has no effect on the system's operation. It is used to provide additional information about the user that the administrator may deem necessary.

The next parameter is the user's home directory. This directory is opened for the user when he or she enters the system.

The last parameter is the command interpreter that will process user requests. The most common command interpreter is /bin/bash. If the user's commands are not supposed to be executed, this parameter is set to /sbin/nologin. The shell parameter for the bin, daemon , and many other accounts is set to /sbin/nologin, because these accounts are not used to enter the system but are only intended for providing internal security for certain programs.

Now, examine the /etc/shadow file structure. Three entries from this file will be enough for an example:

 root:emP$XMJ3/GrkltC4c4h/:12726:0:99999:7::: bin:*:12726:0:99999:7::: daemon:*:12726:0:99999:7:::

Each entry contains several parameters delimited with a colon . Of interest to us are only the first two parameters: login and password. The login (the user name) is used to map the entry in the /etc/shadow file to the corresponding entry in the /etc/passwd file. The actual encrypted password is stored in the second parameter. An asterisk in this field means that this account is locked and the user is not allowed to log in. Thus, accounts for users bin and daemon cannot be used to log into the system.

3.3.2. Password Recovery

What should you do when you forget the password or if a hacker compromised your system and changed the password? This situation cannot be called pleasant, but neither is it unsolvable . If your account has the rights to access /etc/shadow, you can edit this file; otherwise , you can recover the password by booting from a diskette.

Having booted from a diskette, log into the system as root and mount the hard drive (or the partition), on which the /etc directory is located. This is done by executing the following command:

 /sbin/mount -w hda1 /mnt/restore

Now, the /mnt/restore directory (this directory must exist before the command is executed) points to the primary partition of your hard drive, and the file with the password is at the /mnt/restore/etc/shadow path. Open this file in any text editor and remove the root password by simply deleting all text between the first and the second colons. The following is what I obtained in my /etc/shadow file:

 root::12726:0:99999:7:::

Now boot into the system as usual and log in as root. The system will not even ask you to enter the password, because there is none. Do not, however, forget to set a new password, because failing to do this is a security risk.

You can do this by running the passwd root command and following the instructions.

3.3.3. Authentication Modules

The authentication method based on only files /etc/passwd and /etc/shadow is somewhat outdated and makes few features available. The developers of the Linux kernel are trying to remedy the situation by adding new encrypting algorithms. These attempts, however, are purely cosmetic; a cardinal solution is needed.

Sun Microsystems has offered a new solution to implement the authentication process: Pluggable Authentication Modules (PAMs).

The advantage of module authentication is that programs do not have to be recompiled to use them. Modules have been developed for the main authentication methods, such as Kerberos, SecureID, and Lightweight Directory Access Protocol (LDAP).

The configuration files for each service that may use PAMs are located in the /etc/pam.d directory. In most cases, you will not have to create these files manually, because they are installed when the program is installed using the RPM package. But you should know their structure in case there is a need to change some parameters.

Each entry in the configuration file contains four fields delimited by spaces. These are the following:

Module interface Can be one of the following types:
- auth These modules authenticate users and check their privileges.
- account These modules distribute system resources among users.
- session These modules support sessions and register users' actions.
- password These modules set and verify passwords.
Control flag Defines the module's parameters. The following three values can be used:
- Required
- Optional
- Sufficient
Module path Indicates the full path to the module's file.
Module arguments

The following is what the /etc/pam.d/ftp FTP service configuration file looks like:

 #%PAM-1.0 auth       required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed auth       required /lib/security/pam_stack.so service=system-auth auth       required /lib/security/pam_shells.so account    required /lib/security/pam_stack.so service=system-auth session    required /lib/security/pam_stack.so service=system-auth

This information is all you need to know. The service program takes care of the rest without your participation.