Home > Articles > Programming > Android

  • Print
  • + Share This

PAM and the other Configuration File

So far we have discussed discrete PAM-aware applications and how to grant or limit access through PAM by those applications. It turns out that, if a PAM-aware application has no configuration file of its own, Linux-PAM will supply a special set of modules from the /etc/pam.d/other file. This file is normally used to reject all other requests and, by default, will likely appear as in Example 5-24. For example, if you download a PAM-aware application, such as ssh 1.2.27 (see Chapter 11), and fail to provide an ssh configuration file in /etc/ pam.d, then the other file is used, and, if it is as in Example 5-24, then ssh connections will always fail. Furthermore, pam_deny generates no messages whatsoever! Unfortunately this means that you may end up spending a lot of time trying to figure out why something doesn't work. All pam_deny does, as its name suggests, is deny all requests for any available module type.

Example 5-24 A Common /etc/pam.d/other File

Auth    required  /lib/security/pam_deny.so
account  required  /lib/security/pam_deny.so
password  required  /lib/security/pam_deny.so
session  required  /lib/security/pam_deny.so

But there is good news! There is another module, the pam_warn module, that logs to syslog informational messages, including the service requested, the terminal name, the username, the remote username, and the remote host-name. The pam_warn module operates only for module type auth and password. So you may want to modify your /etc/pam.d/other file as in Example 5-25. In this way, all other services that make auth or password requests will have log entries generated. The pam_warn module is not limited to use with pam_deny. It may be used in any auth or password stack to generate additional log messages.

Example 5-25 Administrator Friendly /etc/pam.d/other File

auth   required  /lib/security/pam_warn.so
auth   required  /lib/security/pam_deny.so
account  required  /lib/security/pam_deny.so
password required  /lib/security/pam_warn.so
password required  /lib/security/pam_deny.so
session  required  /lib/security/pam_deny.so

This additional logging capability of pam_warn has obvious debugging advantages, but it also has advantages from the security perspective. For example, if you have identified some suspicious activity, you may want to add pam_warn in the auth stacks surrounding the services in question. You may also want to use the debug argument on those modules that support it for more detailed auditing information. Pay close attention when you do this because your log files will get large quickly. And, if the bad-guys are already in, they're reading the log files, too!

There is one other module in this category. It is the antithesis of pam_deny. It is called pam_permit and—you guessed it—it categorically allows access. It operates for all module types and should be used with great caution, if ever.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.