Subsections

• Default policy
• A word on null passwords
• Disable unused services

Example configuration file entries

Let's look at some examples of pam configuration files. The first example is for the ``other'' or default service. If there is not a specific pam configuration file in /etc/pam.d for a service, this is the configuration file that can be used to ease the integration of new services by providing a default selection of modules appropriate to the local security policy. Or, it can be used to deny access to any application that does not have a specific /etc/pam.d entry. The fields in the configuration file are module-type, control-flag and module-filename. The optional fourth and greater fields are for optional arguments that are specific to the individual modules.

Default policy

If a system is to be considered secure, it had better have a reasonably secure ``other'' entry. The following is a paranoid setting (which is not a bad place to start!):

#

# default configuration: /etc/pam.d/other

#

auth required pam_deny.so

account required pam_deny.so

password required pam_deny.so

session required pam_deny.so

While fundamentally a secure default, this won't give the administrator any feedback about a mis-configured system. For example, such a system is vulnerable to locking everyone out should the configuration file for a specific service be badly written.

The module pam_deny is not very sophisticated, it logs no information when it is invoked. Unless the users of a system contact the administrator when failing to execute a service application, the administrator may go for a long not knowing that his system is mis-configured.

By changing the configuration to the example below would provide a suitable warning to the administrator. Notice the the stacking of pam_warn.so and pam_deny.so.

#

# default configuration: /etc/pam.d/other

#

auth required pam_deny.so

auth required pam_warn.so

account required pam_deny.so

account required pam_warn.so

password required pam_deny.so

password required pam_warn.so

session required pam_deny.so

session required pam_warn.so

With this configuration, whenever an unknown service attempts to access any of the four configuration types, PAM denies authentication (via the pam_deny.so module) and then logs a syslog warning (via the pam_warn.so module). Short of a bug in PAM, this configuration is brutally secure. The only problem with that brutality is it may cause problems if your accidentally delete the configuration of another service. If your /etc/pam.d/login was mistakenly deleted, no one would be able to login!

Here's a little gentler configuration

#

# default configuration: /etc/pam.d/other

#

auth requisite pam_securetty.so

auth required pam_unix.so

auth required pam_warn.so

account required pam_unix.so

account required pam_warn.so

password required pam_unix.so

password required pam_warn.so

session required pam_unix.so

session required pam_warn.so.

The first module (pam_securetty.so) checks to see if the user is root and prevents root from logging in from an insecure terminal. The value requisite for control-flag is used to force immediate authentication failure if the securetty module fails. If this occurs, no more of the auth modules are executed. This has the benefit of preventing root from mistakenly typing a password over an insecure terminal line. This configuration will allow an unknown service to authenticate (via the pam_unix.so module), although it will not allow it to change the user's password. Although it allows authentication by unknown services, it logs a syslog warning whenever such a service attempts authentication.

A word on null passwords

On many linux systems there are a number of accounts used to assign privileges to system services like ftp, apache, news, and databases. These accounts allow services to run as unprivileged users, providing a level of security, because an intruder that compromises the service only has the limited privileges available to that service, rather than the privileges of root. However, allowing these accounts login privileges is a security risk, as they usually have blank (null) passwords. The "nullok" options-argument allows passwordless accounts. It is recommended you remove this argument from any modules of 'auth' type for services that allow login. This is usually the login service, may also include services like rlogin and ssh. So the following line in /etc/pam.d/login:

auth required pam_unix.so nullok

Should be changed to:

auth required pam_unix.so

Disable unused services

If you find you have pam configuration files in /etc/pam.d/ that you're not using, you may want to rename or remove them to prevent their unauthorized use. For example, if you're not using graphical login (Red Hat runlevel 5) then you might want to rename /etc/pam.d/xdm to /etc/pam.d/noxdm. Not finding the file named after the service requesting authentication, PAM will fall back to the /etc/pam.d/other. If you later want to enable the service, rename to it's original name and everything will work as it was intended.