This section discusses some tasks that might be required to make the PAM framework fully functional. In particular, you should be aware of some security issues that are associated with the PAM configuration file.
Task |
Description |
For Instructions |
---|---|---|
Plan for your PAM Installation | Consider configuration issues and make decisions about them before you start the software configuration process. | Planning for PAM |
Add new PAM modules | Sometimes, site-specific modules must be written and installed to cover requirements that are not part of the generic software. This procedure covers the installation process. | How to Add a PAM Module |
Block access through ~/.rhosts | Steps to further increase security by preventing access through ~/.rhosts. | How to Prevent Unauthorized Access From Remote Systems With PAM |
Initiate error reporting | Steps to start the reporting of PAM error messages through syslog. | How to Initiate PAM Error Reporting |
When you are deciding how best to use 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 each module.
Choose any options that are necessary for each module.
Here are some suggestions to consider before you change the PAM 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 that are associated with the modules. These man pages can help you understand how each module functions, what options are available, and the interactions between stacked modules.
If the PAM configuration file is misconfigured or the file becomes corrupted, even superuser might be unable to log in. Since the sulogin command does not use PAM, superuser would then be required to boot the machine into single-user mode and fix the problem.
After you change the /etc/pam.conf file, review the file as much as possible while you are still logged in as superuser. Test all the commands that might have been affected by your changes. An example is adding a new module to the telnet service. In this example, you use the telnet command and verify that your changes make the service behave as expected.
Become superuser or assume an equivalent role.
Determine which control flags and which other options should be used.
Refer to PAM Modules information on the modules.
Copy the new module to /usr/lib/security/sparcv9.
In the Solaris 8 release, the module should be copied to /usr/lib/security.
Set the permissions so that the module file is owned by root and that permissions are 555.
Edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services.
You must test before the system is rebooted in case the configuration file is misconfigured. Run rlogin, su, and telnet before you reboot the system. The service might be a daemon that is spawned only once when the system is booted. Then you must 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 step prevents the reading of the ~/.rhosts files during an rlogin session. Therefore, this step 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 the /etc/inetd.conf file. Changing the PAM configuration file does not prevent the service from being started.
Edit the /etc/syslog.conf file to add any of the following entries for PAM error reporting:
auth.alert – Messages about conditions that should be fixed immediately
auth.crit – Critical messages
auth.err – Error messages
auth.info – Informational messages
auth.debug – Debugging messages
Restart the syslog daemon, or send a SIGHUP signal to the daemon to activate the PAM error reporting.
In the following example, all alert messages are displayed 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. The pamlog file is capable of logging a large amount of information.