diff --git a/en_US.ISO8859-1/articles/hats/article.sgml b/en_US.ISO8859-1/articles/hats/article.sgml index f50e3669ed..b7a1758cce 100644 --- a/en_US.ISO8859-1/articles/hats/article.sgml +++ b/en_US.ISO8859-1/articles/hats/article.sgml @@ -1,128 +1,129 @@ %man; %freebsd; %authors; %teams; %mailing-lists; ]>
Working with Hats Warner Losh Contributed by $FreeBSD$ 2002 + 2003 Warner Losh This is not an official statement from core, but rather one core member's personal interpretation of core's position, both as a sitting member of core and as a former security officer. This is only a guideline, not as a cudgel for grievances. Much like &man.style.9; is a guideline for the source code, this document is not intended as an absolute straight jacket. When core appoints someone to a hat, they expect that person to be responsible for an area of the source code tree. Core expects that person to be the final authority in that area of the tree, or have enough self knowledge to know that they are not and to seek qualified help. Core expects that person to guide development in that area of the tree. Sometimes this means taking an pro-active role in day to day affairs, while other times this means taking a reactive role in reviewing committed code. When people submit patches that potentially impact this area of the tree, core expects the hat or his appointed deputies to review the patches appropriately. Core expects that the hat will work with the patch submitter to correct issues that there may be with the patches. Core expects the hat to offer solutions and work with the submitter to reach a compromise. Core expects the hat to be courteous. It is reasonable for hats to request that normal project rules be followed when reviewing patches (eg, that they generally conform to &man.style.9; or the prevailing style of the file, that style and content changes be separated, etc). When a dispute arises, core expects the hat to make his or her best efforts to compromise or otherwise resolve the dispute. The hat is expected to be courteous to all parties involved. In extreme cases, core recognizes that hats may need to wield a big stick and say no, that is not acceptable and cannot go in (or must be backed out). Core views this last power as one of last resort, and would frown on hats using that either too often or as the first response. Often real life interferes with a hat's ability to perform their duties. A condition that core generally imposes upon the hats of the world is that they have a deputy that can act in their absence. This deputy is expected to be an active participant in the team that the hat puts together and should be conversant with all the issues that surround the part of the tree that the hat is guiding. The deputy is expected to be able to act in the absence of the hat. For example, the security officer deputies send out security advisories when the SO is not around. In extreme cases, the deputy can defer an issue until the hat returns, but that is expected to be the exception rather than the rule, especially if the hat's return is far in the future. Hats are answerable to core. If they are doing good jobs, core will leave them alone. If they are doing a bad job, core has the option to remove them. Hats are expected to work with core if core has issues with their performance of their duties They serve at the pleasure of core. Core sometimes will impose additional, specific requirements for a given hat that does not apply to all hats. These conditions may change over time. Committers and others working with hats are expected to use common sense, and be polite to the hats. They are expected to work with the hat and his team to come to a solution acceptable to everybody. In the event that no compromise can be reached, the committers are expected to accept the decisions of the hat with good grace. In exceptional cases, these decisions can be appealed to core. However, core generally will not override the decisions of the hats that it appoints unless the hat acted in bad faith or arbitrarily. Core is not a technical review board, and has created the hats as mini-TRBs to give dispute resolution a proper framework. If a committer feels that a hat is abusing his or her power, or being regularly rude to contributors, then they should bring the matter to core. This problem can be technical, social, procedural, or some combination or subset of these. Core will hear the case and reach a decision, and expects both sides to abide by their decision. Core appreciates specific complaints rather than general ones as those are easier to resolve. Core expects committers to work together in the appropriate mailing lists to resolve their issues. The hat and his team should be relatively rarely involved in their role as hat, and instead should usually be just another committer. (The one exception to this is the security officer hat, which needs to secretly solve vulnerabilities before they are announced.) The hat should be a first among equals, not a chairman.
diff --git a/en_US.ISO8859-1/articles/pam/article.sgml b/en_US.ISO8859-1/articles/pam/article.sgml index e558431ec7..da8e847ddd 100644 --- a/en_US.ISO8859-1/articles/pam/article.sgml +++ b/en_US.ISO8859-1/articles/pam/article.sgml @@ -1,1302 +1,1303 @@ %man; ]>
Pluggable Authentication Modules $FreeBSD$ This article describes the underlying principles and mechanisms of the Pluggable Authentication Modules (PAM) library, and explains how to configure PAM, how to integrate PAM into applications, and how to write PAM modules. 2001 2002 + 2003 Networks Associates Technology, Inc. Dag-Erling Smørgrav Contributed by This article was written for the FreeBSD Project by ThinkSec AS and Network Associates Laboratories, the Security Research Division of Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (CBOSS), as part of the DARPA CHATS research program.
Introduction The Pluggable Authentication Modules (PAM) library is a generalized API for authentication-related services which allows a system administrator to add new authentication methods simply by installing new PAM modules, and to modify authentication policies by editing configuration files. PAM was defined and developed in 1995 by Vipin Samar and Charlie Lai of Sun Microsystems, and has not changed much since. In 1997, the Open Group published the X/Open Single Sign-on (XSSO) preliminary specification, which standardized the PAM API and added extensions for single (or rather integrated) sign-on. At the time of this writing, this specification has not yet been adopted as a standard. Although this article focuses primarily on FreeBSD 5.x, which uses OpenPAM, it should be equally applicable to FreeBSD 4.x, which uses Linux-PAM, and other operating systems such as Linux and Solaris.
Trademarks Sun, Sun Microsystems and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. UNIX and The Open Group are trademarks or registered trademarks of The Open Group. All other brand or product names mentioned in this document may be trademarks or registered trademarks of their respective owners.
Terms and conventions
Definitions The terminology surrounding PAM is rather confused. Neither Samar and Lai's original paper nor the XSSO specification made any attempt at formally defining terms for the various actors and entities involved in PAM, and the terms that they do use (but do not define) are sometimes misleading and ambiguous. The first attempt at establishing a consistent and unambiguous terminology was a whitepaper written by Andrew G. Morgan (author of Linux-PAM) in 1999. While Morgan's choice of terminology was a huge leap forward, it is in this author's opinion by no means perfect. What follows is an attempt, heavily inspired by Morgan, to define precise and unambiguous terms for all actors and entities involved in PAM. account The set of credentials the applicant is requesting from the arbitrator. applicant The user or entity requesting authentication. arbitrator The user or entity who has the privileges necessary to verify the applicant's credentials and the authority to grant or deny the request. chain A sequence of modules that will be invoked in response to a PAM request. The chain includes information about the order in which to invoke the modules, what arguments to pass to them, and how to interpret the results. client The application responsible for initiating an authentication request on behalf of the applicant and for obtaining the necessary authentication information from him. facility One of the four basic groups of functionality provided by PAM: authentication, account management, session management and authentication token update. module A collection of one or more related functions implementing a particular authentication facility, gathered into a single (normally dynamically loadable) binary file and identified by a single name. policy The complete set of configuration statements describing how to handle PAM requests for a particular service. A policy normally consists of four chains, one for each facility, though some services do not use all four facilities. server The application acting on behalf of the arbitrator to converse with the client, retrieve authentication information, verify the applicant's credentials and grant or deny requests. service A class of servers providing similar or related functionality and requiring similar authentication. PAM policies are defined on a per-service basis, so all servers that claim the same service name will be subject to the same policy. session The context within which service is rendered to the applicant by the server. One of PAM's four facilities, session management, is concerned exclusively with setting up and tearing down this context. token A chunk of information associated with the account, such as a password or passphrase, which the applicant must provide to prove his identity. transaction A sequence of requests from the same applicant to the same instance of the same server, beginning with authentication and session set-up and ending with session tear-down.
Usage examples This section aims to illustrate the meanings of some of the terms defined above by way of a handful of simple examples.
Client and server are one This simple example shows alice &man.su.1;'ing to root. &prompt.user; whoami alice &prompt.user; ls -l `which su` -r-sr-xr-x 1 root wheel 10744 Dec 6 19:06 /usr/bin/su &prompt.user; su - Password: xi3kiune &prompt.root; whoami root The applicant is alice. The account is root. The &man.su.1; process is both client and server. The authentication token is xi3kiune. The arbitrator is root, which is why &man.su.1; is setuid root.
Client and server are separate The example below shows eve try to initiate an &man.ssh.1; connection to login.example.com, ask to log in as bob, and succeed. Bob should have chosen a better password! &prompt.user; whoami eve &prompt.user; ssh bob@login.example.com bob@login.example.com's password: god Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001 Welcome to FreeBSD! &prompt.user; The applicant is eve. The client is Eve's &man.ssh.1; process. The server is the &man.sshd.8; process on login.example.com The account is bob. The authentication token is god. Although this is not shown in this example, the arbitrator is root.
Sample policy The following is FreeBSD's default policy for sshd: sshd auth required pam_nologin.so no_warn sshd auth required pam_unix.so no_warn try_first_pass sshd account required pam_login_access.so sshd account required pam_unix.so sshd session required pam_lastlog.so no_fail sshd password required pam_permit.so This policy applies to the sshd service (which is not necessarily restricted to the &man.sshd.8; server.) auth, account, session and password are facilities. pam_nologin.so, pam_unix.so, pam_login_access.so, pam_lastlog.so and pam_permit.so are modules. It is clear from this example that pam_unix.so provides at least two facilities (authentication and account management.)
Conventions This section has not yet been written.
PAM Essentials
Facilities and primitives The PAM API offers six different authentication primitives grouped in four facilities, which are described below. auth Authentication. This facility concerns itself with authenticating the applicant and establishing the account credentials. It provides two primitives: &man.pam.authenticate.3; authenticates the applicant, usually by requesting an authentication token and comparing it with a value stored in a database or obtained from an authentication server. &man.pam.setcred.3; establishes account credentials such as user ID, group membership and resource limits. account Account management. This facility handles non-authentication-related issues of account availability, such as access restrictions based on the time of day or the server's work load. It provides a single primitive: &man.pam.acct.mgmt.3; verifies that the requested account is available. session Session management. This facility handles tasks associated with session set-up and tear-down, such as login accounting. It provides two primitives: &man.pam.open.session.3; performs tasks associated with session set-up: add an entry in the utmp and wtmp databases, start an SSH agent, etc. &man.pam.close.session.3; performs tasks associated with session tear-down: add an entry in the utmp and wtmp databases, stop the SSH agent, etc. password Password management. This facility is used to change the authentication token associated with an account, either because it has expired or because the user wishes to change it. It provides a single primitive: &man.pam.chauthtok.3; changes the authentication token, optionally verifying that it is sufficiently hard to guess, has not been used previously, etc.
Modules Modules are a very central concept in PAM; after all, they are the M in PAM. A PAM module is a self-contained piece of program code that implements the primitives in one or more facilities for one particular mechanism; possible mechanisms for the authentication facility, for instance, include the UNIX password database, NIS, LDAP and Radius.
Module Naming FreeBSD implements each mechanism in a single module, named pam_mechanism.so (for instance, pam_unix.so for the Unix mechanism.) Other implementations sometimes have separate modules for separate facilities, and include the facility name as well as the mechanism name in the module name. To name one example, Solaris has a pam_dial_auth.so.1 module which is commonly used to authenticate dialup users.
Module Versioning FreeBSD's original PAM implementation, based on Linux-PAM, did not use version numbers for PAM modules. This would commonly cause problems with legacy applications, which might be linked against older versions of the system libraries, as there was no way to load a matching version of the required modules. OpenPAM, on the other hand, looks for modules that have the same version number as the PAM library (currently 2), and only falls back to an unversioned module if no versioned module could be loaded. Thus legacy modules can be provided for legacy applications, while allowing new (or newly built) applications to take advantage of the most recent modules. Although Solaris PAM modules commonly have a version number, they're not truly versioned, because the number is a part of the module name and must be included in the configuration.
Chains and policies When a server initiates a PAM transaction, the PAM library tries to load a policy for the service specified in the &man.pam.start.3; call. The policy specifies how authentication requests should be processed, and is defined in a configuration file. This is the other central concept in PAM: the possibility for the admin to tune the system security policy (in the wider sense of the word) simply by editing a text file. A policy consists of four chains, one for each of the four PAM facilities. Each chain is a sequence of configuration statements, each specifying a module to invoke, some (optional) parameters to pass to the module, and a control flag that describes how to interpret the return code from the module. Understanding the control flags is essential to understanding PAM configuration files. There are four different control flags: required Success is required, but the chain continues no matter what this module returns, so that later modules can override it. requisite A negative result from this module will immediately terminate the chain and deny the request. sufficient A positive result from this module will immediately terminate the chain and grant the request. On failure, the chain continues. optional A negative result from this module will be ignored. When a server invokes one of the six PAM primitives, PAM retrieves the chain for the facility the primitive belongs to, and invokes each of the modules listed in the chain, in the order they are listed, until it reaches the end, or determines that no further processing is necessary (either because a sufficient module succeeded, or because a requisite module failed.) The request is granted if and only if at least one module was invoked, and all non-optional modules succeeded. Note that it is possible, though not very common, to have the same module listed several times in the same chain. For instance, a module that looks up user names and passwords in a directory server could be invoked multiple times with different parameters specifying different directory servers to contact. PAM treat different occurrences of the same module in the same chain as different, unrelated modules.
Transactions The lifecycle of a typical PAM transaction is described below. Note that if any of these steps fails, the server should report a suitable error message to the client and abort the transaction. If necessary, the server obtains arbitrator credentials through a mechanism independent of PAM—most commonly by virtue of having been started by root, or of being setuid root. The server calls &man.pam.start.3; to initialize the PAM library and specify its service name and the target account, and register a suitable conversation function. The server obtains various information relating to the transaction (such as the applicant's user name and the name of the host the client runs on) and submits it to PAM using &man.pam.set.item.3;. The server calls &man.pam.authenticate.3; to authenticate the applicant. The server calls &man.pam.acct.mgmt.3; to verify that the requested account is available and valid. If the password is correct but has expired, &man.pam.acct.mgmt.3; will return PAM_NEW_AUTHTOK_REQD instead of PAM_SUCCESS. If the previous step returned PAM_NEW_AUTHTOK_REQD, the server now calls &man.pam.chauthtok.3; to force the client to change the authentication token for the requested account. Now that the applicant has been properly authenticated, the server calls &man.pam.setcred.3; to establish the credentials of the requested account. It is able to do this because it acts on behalf of the arbitrator, and holds the arbitrator's credentials. Once the correct credentials have been established, the server calls &man.pam.open.session.3; to set up the session. The server now performs whatever service the client requested—for instance, provide the applicant with a shell. Once the server is done serving the client, it calls &man.pam.close.session.3; to tear down the session. Finally, the server calls &man.pam.end.3; to notify the PAM library that it is done and that it can release whatever resources it has allocated in the course of the transaction.
PAM Configuration
Location of configuration files The traditional PAM configuration file is /etc/pam.conf. This file contains all the PAM policies for your system. Each line of the file describes one step in a chain, as shown below: login auth required pam_nologin.so no_warn The fields are, in order: service name, facility name, control flag, module name, and module arguments. Any additional fields are interpreted as additional module arguments. A separate chain is constructed for each service / facility pair, so while the order in which lines for the same service and facility appear is significant, the order in which the individual services and facilities are listed is not—except that entries for the other service, which serves as a fall-back, should come last. The examples in the original PAM paper grouped configuration lines by facility, and Solaris' stock pam.conf still does that, but FreeBSD's stock configuration groups configuration lines by service. Either way is fine; either way makes equal sense. OpenPAM and Linux-PAM offer an alternate configuration mechanism, where policies are contained in separate files, named for the service they apply to, in /etc/pam.d/, with only four fields instead of five—the service name field is omitted. This is the preferred mechanism in FreeBSD 5.x. Note, however, that if /etc/pam.conf exists, and contains configuration statements for services which do not have a specific policy in /etc/pam.d/, it will be used as a fall-back for these services. The great advantage of /etc/pam.d/ over /etc/pam.conf is that it is possible to use the same policy for multiple services by linking each service name to a same policy file. For instance, to use the same policy for the su and sudo services, one could do as follows: &prompt.root; cd /etc/pam.d &prompt.root; ln -s su sudo This works because the service name is determined from the file name rather than specified in the policy file, so the same file can be used for multiple differently-named services. One other advantage is that third-party software can easily install policies for their services without the need to edit /etc/pam.conf. True to the FreeBSD tradition, OpenPAM will even look for policy files in /usr/local/etc/pam.d/ if no configuration for the requested service is present in /etc/pam.d/ or /etc/pam.conf. Finally, whichever configuration mechanism you choose, the magic policy other is used as a fall-back for any service that does not have its own policy.
Breakdown of a configuration line As explained in the section, each line in /etc/pam.conf consists of four or more fields: the service name, the facility name, the control flag, the module name, and zero or more module arguments. The service name is generally (though not always) the name of the application the statement applies to. If you are unsure, refer to the individual application's documentation to determine what service name it uses. Note that if you use /etc/pam.d/ instead of /etc/pam.conf, the service name is specified by the name of the policy file, and omitted from the actual configuration lines, which then start with the facility name. The facility is one of the four facility keywords described in the section. Likewise, the control flag is one of the four keywords described in the section, describing how to interpret the return code from the module. Linux-PAM supports an alternate syntax that lets you specify the action to associate with each possible return code, but this should be avoided as it is non-standard and closely tied in with the way Linux-PAM dispatches service calls (which differs greatly from the way Solaris and OpenPAM do it.) Unsurprisingly, OpenPAM does not support this syntax.
Policies To configure PAM correctly, it is essential to understand how policies are interpreted. When an application calls &man.pam.start.3;, the PAM library loads the policy for the specified service and constructs four module chains (one for each facility.) If one or more of these chains are empty, the corresponding chains from the policy for the other service are substituted. When the application later calls one of the six PAM primitives, the PAM library retrieves the chain for the corresponding facility and calls the appropriate service function in each module listed in the chain, in the order in which they were listed in the configuration. After each call to a service function, the module type and the error code returned by the service function are used to determine what happens next. With a few exceptions, which we will discuss later, the following table applies: PAM chain execution summary PAM_SUCCESS PAM_IGNORE other required - - fail = true requisite - - fail = true, break sufficient if (!fail) break - fail = true optional - - -
If fail is true at the end of a chain, or when a break is reached, the dispatcher returns the error code returned by the first module that failed. Otherwise, it returns PAM_SUCCESS. The first exception of note is that the error code PAM_NEW_AUTHTOK_REQD is treated like a success, except that if no module failed, and at least one module returned PAM_NEW_AUTHTOK_REQD, the dispatcher will return PAM_NEW_AUTHTOK_REQD. The second exception is that &man.pam.setcred.3; treats sufficient modules as if they were required. The third and final exception is that &man.pam.chauthtok.3; runs the entire chain twice (once for preliminary checks and once to actually set the password), and in the preliminary phase it treats sufficient modules as if they were required.
FreeBSD PAM Modules
&man.pam.deny.8; The &man.pam.deny.8; module is one of the simplest modules available; it responds to any request with PAM_AUTH_ERR. It is useful for quickly disabling a service (add it to the top of every chain), or for terminating chains of sufficient modules.
&man.pam.echo.8; The &man.pam.echo.8; module simply passes its arguments to the conversation function as a PAM_TEXT_INFO message. It is mostly useful for debugging, but can also serve to display messages such as Unauthorized access will be prosecuted before starting the authentication procedure.
&man.pam.exec.8; The &man.pam.exec.8; module takes its first argument to be the name of a program to execute, and the remaining arguments are passed to that program as command-line arguments. One possible application is to use it to run a program at login time which mounts the user's home directory.
&man.pam.ftp.8; The &man.pam.ftp.8; module
&man.pam.ftpusers.8; The &man.pam.ftpusers.8; module
&man.pam.group.8; The &man.pam.group.8; module accepts or rejects applicants on the basis of their membership in a particular file group (normally wheel for &man.su.1;). It is primarily intended for maintaining the traditional behaviour of BSD &man.su.1;, but has many other uses, such as excluding certain groups of users from a particular service.
&man.pam.kerberosIV.8; The &man.pam.kerberosIV.8; module
&man.pam.krb5.8; The &man.pam.krb5.8; module
&man.pam.ksu.8; The &man.pam.ksu.8; module
&man.pam.lastlog.8; The &man.pam.lastlog.8; module
&man.pam.login.access.8; The &man.pam.login.access.8; module
&man.pam.nologin.8; The &man.pam.nologin.8; module
&man.pam.opie.8; The &man.pam.opie.8; module implements the &man.opie.4; authentication method. The &man.opie.4; system is a challenge-response mechanism where the response to each challenge is a direct function of the challenge and a passphrase, so the response can be easily computed just in time by anyone possessing the passphrase, eliminating the need for password lists. Moreover, since &man.opie.4; never reuses a challenge that has been correctly answered, it is not vulnerable to replay attacks.
&man.pam.opieaccess.8; The &man.pam.opieaccess.8; module is a companion module to &man.pam.opie.8;. Its purpose is to enforce the restrictions codified in &man.opieaccess.5;, which regulate the conditions under which a user who would normally authenticate herself using &man.opie.4; is allowed to use alternate methods. This is most often used to prohibit the use of password authentication from untrusted hosts. In order to be effective, the &man.pam.opieaccess.8; module must be listed as requisite immediately after a sufficient entry for &man.pam.opie.8;, and before any other modules, in the auth chain.
&man.pam.passwdqc.8; The &man.pam.passwdqc.8; module
&man.pam.permit.8; The &man.pam.permit.8; module is one of the simplest modules available; it responds to any request with PAM_SUCCESS. It is useful as a placeholder for services where one or more chains would otherwise be empty.
&man.pam.radius.8; The &man.pam.radius.8; module
&man.pam.rhosts.8; The &man.pam.rhosts.8; module
&man.pam.rootok.8; The &man.pam.rootok.8; module reports success if and only if the real user id of the process calling it (which is assumed to be run by the applicant) is 0. This is useful for non-networked services such as &man.su.1; or &man.passwd.1;, to which the root should have automatic access.
&man.pam.securetty.8; The &man.pam.securetty.8; module
&man.pam.self.8; The &man.pam.self.8; module reports success if and only if the names of the applicant matches that of the target account. It is most useful for non-networked services such as &man.su.1;, where the identity of the applicant can be easily verified.
&man.pam.ssh.8; The &man.pam.ssh.8; module
&man.pam.tacplus.8; The &man.pam.tacplus.8; module
&man.pam.unix.8; The &man.pam.unix.8; module implements traditional Unix password authentication, using &man.getpwnam.3; to obtain the target account's password and compare it with the one provided by the applicant. It also provides account management services (enforcing account and password expiration times) and password-changing services. This is probably the single most useful module, as the great majority of admins will want to maintain historical behaviour for at least some services.
PAM Application Programming This section has not yet been written.
PAM Module Programming This section has not yet been written.
Sample PAM Application The following is a minimal implementation of &man.su.1; using PAM. Note that it uses the OpenPAM-specific &man.openpam.ttyconv.3; conversation function, which is prototyped in security/openpam.h. If you wish build this application on a system with a different PAM library, you will have to provide your own conversation function. A robust conversation function is surprisingly difficult to implement; the one presented in the appendix is a good starting point, but should not be used in real-world applications. Sample PAM Module The following is a minimal implementation of &man.pam.unix.8;, offering only authentication services. It should build and run with most PAM implementations, but takes advantage of OpenPAM extensions if available: note the use of &man.pam.get.authtok.3;, which enormously simplifies prompting the user for a password. Sample PAM Conversation Function The conversation function presented below is a greatly simplified version of OpenPAM's &man.openpam.ttyconv.3;. It is fully functional, and should give the reader a good idea of how a conversation function should behave, but it is far too simple for real-world use. Even if you're not using OpenPAM, feel free to download the source code and adapt &man.openpam.ttyconv.3; to your uses; we believe it to be as robust as a tty-oriented conversation function can reasonably get. Further Reading This is a list of documents relevant to PAM and related issues. It is by no means complete. Papers <ulink url="http://www.sun.com/software/solaris/pam/pam.external.pdf"> Making Login Services Independent of Authentication Technologies</ulink> Samar Vipin Lai Charlie Sun Microsystems <ulink url="http://www.opengroup.org/pubs/catalog/p702.htm">X/Open Single Sign-on Preliminary Specification</ulink> The Open Group 1-85912-144-6 June 1997 <ulink url="http://www.kernel.org/pub/linux/libs/pam/pre/doc/current-draft.txt"> Pluggable Authentication Modules</ulink> Morgan Andrew G. October 6, 1999 User Manuals <ulink url="http://www.sun.com/software/solaris/pam/pam.admin.pdf">PAM Administration</ulink> Sun Microsystems Related Web pages <ulink url="http://openpam.sourceforge.net/">OpenPAM homepage</ulink> Smørgrav Dag-Erling ThinkSec AS <ulink url="http://www.kernel.org/pub/linux/libs/pam/">Linux-PAM homepage</ulink> Morgan Andrew G. <ulink url="http://wwws.sun.com/software/solaris/pam/">Solaris PAM homepage</ulink> Sun Microsystems