The section below discusses some of the tasks that may be required to make the PAM framework fully functional. In particular, you should be aware of some of the security issues associated with the PAM configuration file.
When deciding how best to employ PAM in your environment, start by focusing on these issues:
Determine what your needs are, especially which modules you should select.
Identify the services that need special attention; use OTHER if appropriate.
Decide on the order in which the modules should be run.
Select the control flag for that module.
Choose any options necessary for the module.
Here are some suggestions to consider before changing the configuration file:
Use the OTHER entry for each module type so that every application does not have to be included.
Make sure to consider the security implications of the sufficient and optional control flags.
Review the man pages associated with the modules to understand how each module will function, what options are available, and the interactions between stacked modules.
If the PAM configuration file is misconfigured or gets corrupted, it is possible that even the superuser would be unable to log in. Since sulogin does not use PAM, the superuser would then be required to boot the machine into single user mode and fix the problem.
After changing the /etc/pam.conf file, review it as much as possible 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.
Become superuser.
Determine which control flags and other options should be used.
Refer to "PAM Modules" information on the module.
Copy the new module to /usr/lib/security.
Set the permissions so that the module file is owned by root and permissions are 555.
Edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services.
It is very important to do some testing before the system is rebooted in case the configuration file is misconfigured. Run rlogin, su, and telnet before rebooting the system. If the service is a daemon spawned only once when the system is booted, it may be necessary to reboot the system before you can verify that the module has been added.
Remove the rlogin auth rhosts_auth.so.1 entry from the PAM configuration file. This prevents reading the ~/.rhosts files during an rlogin session and therefore prevents unauthenticated access to the local system from remote systems. All rlogin access requires a password, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.
To prevent other unauthenticated access to the ~/.rhosts files, remember to disable the rsh service. The best way to disable a service is to remove the service entry from /etc/inetd.conf. Changing the PAM configuration file does not prevent the service from being started.
Edit the /etc/syslog.conf to add any of the following PAM error reporting entries:
Restart the syslog daemon or send a SIGHUP signal to it to activate the PAM error reporting.
The example below 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.