21.4. Modular Authentication for UnixTraditionally, programs wishing to authenticate a user (such as the login program or the ftpd daemon) have had to know how to authenticate a user; they have had to understand and implement whatever authentication method or methods were to be used. In a Unix system, this means that these programs have to do all of the following to authenticate a user:
odular authentication takes a different approach. With it, you modify all the authenticating programs (e.g., login, ftpd) once, to make them talk to an authentication service instead of doing the authentication themselves. All of the details of the authentication mechanism -- for example, what to prompt the user with, how to validate the user's response, etc. -- are then handled by the authentication service. When you want to add or modify authentication methods, you do so by changing the authentication service (which is modular and designed to accommodate such changes), not by changing the individual authenticating programs.
21.4.1. The TIS FWTK Authentication ServerThe authentication server in TIS FWTK is a modular solution for authenticating users coming in from the Internet. The server implements a variety of authentication mechanisms, such as standard reusable passwords (not recommended), S/Key, Security Dynamics SecurID cards, and Digital Pathways SNK-004 cards. In addition, the server is modular and extensible, and is designed so that new authentication mechanisms can easily be integrated.
A single authentication server can handle any number of client machines and programs, and any number of different authentication methods; different users within the same server can use different authentication methods. For example, some might use S/Key while some might use the Digital Pathways SNK-004 cards.
When a client program (such as login or ftpd) wishes to authenticate someone using the TIS FWTK authentication server, it has to go through the following steps:
The authentication server consults its databases to determine how to authenticate that user and determines the appropriate prompt for the authentication mechanism for that user. For example:
Figure 21-2. How the TIS FWTK authentication server worksTIS FWTK includes a number of programs (such as ftpd) that, in addition to other modifications and enhancements for security, have already been modified to use the authentication server. Converting an existing program to use the authentication server, rather than traditional Unix passwords, is pretty straightforward. It typically involves only 20 or so lines of C code, examples of which are given in the toolkit.
The toolkit also includes some programs to support binary-only systems where you don't have the source to modify. For example, for systems in which you don't have the source code to the login program available for modification, the toolkit includes a program you can use as the user's shell (which is specified for each user in the /etc/passwd file) instead of one of the normal shells (e.g., /bin/csh or /bin/sh) This replacement shell authenticates the user with the authentication server, and if the user passes, starts his or her real shell.
220.127.116.11. Problems with the authentication serverThe major problem in running an authentication server is getting secure communication between the client and the server. An attacker who can convincingly pretend to be the authentication server can authenticate as anybody.
Some configurations may have additional problems; for example, using shell replacement can produce problems because not all programs deal well with situations in which a user's shell environment variable and the entry for that user in the /etc/passwd file do not match.
21.4.2. Pluggable Authentication Modules (PAM)PAM is a more recent system for providing modular authentication, which uses an even more flexible mechanism than the TIS FWTK authentication server. The basic principle is much the same; programs that need to do authentication are modified to use the PAM system, after which you can completely control what kind of authentication they use through PAM, without making further changes to the individual programs. PAM differs from the authentication server in that it is a local service; PAM operates by dynamically loading authentication modules into applications that have been configured to use them. Authentication modules execute with the same privileges as the application that loaded them.
A program can ask PAM to authenticate a user or to change a password. The password change feature saves users from having to learn a new password change mechanism for each new authentication mechanism.
An administrator can configure PAM to do extra work in addition to authenticating the user. For instance, it can grant or deny access based on criteria other than whether or not the user authenticated properly. This allows you to control what time of day people can use a service, or how many simultaneous users there can be, or whether or not they're accessible from the machine's console. PAM can also set up the environment that the service will execute in, by setting environment variables or by running programs (for instance, it can use chroot to limit the parts of the filesystem that the service has access to).
Authentication modules can be stacked up, either to allow for fail-over (if you can't authenticate one way, try another) or to enforce complicated rules (allow George to log in only at the console and only between 3:00 and 5:00 in the morning, but allow everybody else to log in from the local network with reusable passwords, or from the Internet with a one-time password). It's also easy to add new authentication modules, but you should use new modules with caution. When you trust a piece of code to authenticate users, you are trusting it with the security of your system; that's not something you should do lightly.
PAM is an extraordinarily flexible system, and as a natural consequence, it can be hard to configure. Configuration errors will often result in an unusable computer, but it's also easy to accidentally produce a configuration that has unexpected insecurities. The module-stacking features, for instance, provide any number of ways to accidentally allow access that you intended to deny. Effectively, they give you an entire programming language with obscure and varying syntax, and an error as simple as using the keyword "required" instead of "requisite" can have unfortunate consequences.
Like any powerful tool, PAM should be used with caution:
No matter how you set up the configuration files, you will need to specify a default behavior for the service called "other", which will be used if there is no specific information for a PAM-enabled service. You should set this up so that it denies access and logs this fact; this way, if you accidentally install a PAM-enabled service without installing configuration information for it, you will not grant access to it. Of course, if you accidentally remove the configuration for an existing service, you will turn off all access to it. This is unpleasant, but not as unpleasant as a compromised machine.
Copyright © 2002 O'Reilly & Associates. All rights reserved.