Solaris Advanced System Administrator's Guide, Second Edition:Using Authentication Services

Table of Contents

Planning for PAM

When deciding how best to use PAM in your environment, start by focusing on the following issues:

• Determine what your needs are, especially which modules you should use.

• Identify the services that need special attention. Use other if appropriate.

• Decide on the order in which the modules should be run.

• Choose the control flag for that module.

• Choose any options needed for the module.

Consider the following suggestions before changing the configuration file:

• Use the other entry for each module type so that you do not have to include every application.

• Make sure to consider the security implications of the sufficient and optional control flags.

• Review the manual pages associated with the modules to understand how each module functions, what options are available, and the interactions between stacked modules.

CAUTION! If the PAM configuration file is misconfigured or becomes corrupted, it is possible that even the superuser would not be able to log in. If the configuration file does become corrupted, you can boot in single-user mode and fix the problem because sulogin does not use PAM.

After you change the /etc/pam.conf file, review it carefully while still logged in as superuser. Test all of the commands that might have been affected by your changes. For example, if you added a new module to the telnet service, use the telnet command and verify that the changes you made behave as expected.

Configuring PAM

This section describes how to prevent unauthorized access from remote systems, initiate PAM error reporting, and add a PAM module.

Preventing Unauthorized Access from Remote Systems with PAM

To prevent unauthorized access from remote systems with PAM, remove the rlogin auth rhosts_auth.so.1 entry from the /etc/pam.conf configuration file. Without this entry, the ~/.rhosts files are not read during an rlogin session. Unauthenticated access to the local system from remote systems is prevented. All rlogin access requires a password, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.

NOTE: To prevent other unauthenticated access to the ~/.rhosts files, remember to also disable the rsh service. The best way to disable a service is to comment out or remove the service entry from the /etc/inetd.conf file. Changing the PAM configuration file does not prevent the service from being started.

Initiating PAM Error Reporting

You can display five different levels of PAM error reporting by adding entries to the /etc/syslog file:

• auth.alert displays messages about conditions that should be fixed immediately.

• auth.crit displays critical messages.

• auth.err displays error messages.

• auth.info displays informational messages.

• auth.debug displays debugging messages.

As with any other configuration entry in the syslog file, the entry consists of two tab-separated fields:

<selector>   <action>

The <selector> field is one of the five levels of PAM error reporting. The <action> field indicates where to forward the message. Values for this field can have one of four forms:

• A filename, beginning with a leading slash, which indicates that messages specified by the selector are to be written to the specified file. The file is opened in append mode.

• A comma-separated list of usernames, which indicates that messages specified by the selector are to be written to the named users if they are logged in.

• An asterisk, which indicates that messages specified by the selector are to be written to all logged-in users.

• The name of a remote host, prefixed with an at sign (@), such as @server, which indicates that messages specified by the selector are to be forwarded to the syslogd on the named host.

Blank lines are ignored. Lines with a pound sign (#) as the first non-white character are treated as comments. Refer to the syslog.conf(4) manual page for more information.

To initiate PAM error reporting:

1. Edit the /etc/syslog.conf file and add a line for the <selector> and <action> you want to use for error reporting. Remember to use a tab as the separator character.

2. Restart the syslog daemon or send a SIGHUP signal to it to activate the PAM error reporting.

The following example displays all alert messages on the console. Critical messages are mailed to root. Informational and debug messages are added to the /var/log/pamlog file:

auth.alert /dev/console
auth.crit `root'
auth.info;auth.debug  /var/log/pamlog

Each line in the log contains a time stamp, the name of the system that generated the message, and the message itself. The pamlog file is capable of logging a large amount of information. Be sure to monitor the size of the log and prune it periodically to delete old information.

Adding a PAM Module

You can add new PAM modules. The /usr/lib/security model contains a pam_sample.so.1 ELF executable file that you can use as a model for creating new modules.

CAUTION! It is very important to test any changes to the /etc/pam.conf configuration file before you reboot the system to detect any misconfiguration errors. Run rlogin, su, and telnet to test and verify expected access results before you reboot the system. However, if the service is a daemon spawned only once when the system is booted, you may need to reboot the system before you can verify that module.

To add a PAM module:

1. Become superuser.

2. Determine which control flags and other options you want to use.

3. Create the new module.

4. Copy the new module to /usr/lib/security.

5. Set permissions so that the module file is owned by root and permissions are set to 555.

6. Edit the /etc/pam.conf file and add the module to the appropriate services.

Table of Contents