|
|
The Pluggable Authentication Module (PAM) framework lets you plug in new authentication technologies without changing system entry services, such as login, ftp, telnet, and so on. You can also use PAM to integrate the UNIX login with other security mechanisms, such as Kerberos. Mechanisms for account, credential, session, and password management can also be plugged in by using this framework.
The PAM framework allows you to configure the use of system entry services (ftp, login, telnet, or rsh, for example) for user authentication. Following are some benefits that PAM provides:
Flexible configuration policy
Per-application authentication policy
The ability to choose a default authentication mechanism
Multiple passwords on high-security systems
Ease of use for the end user
No retyping of passwords if the passwords are the same for different mechanisms
The ability to prompt the user for passwords for multiple authentication methods without having the user enter multiple commands
The ability to pass optional parameters to the user authentication services
The ability to implement a site-specific security policy without having to change the system entry services
The PAM software consists of a library, various service modules, and a configuration file. Solaris commands or daemons that take advantage of the PAM interfaces are also included.
Applications such as ftp, telnet, and login use the PAM library to call the configuration policy. The pam.conf file defines which modules to use and in what order the modules are to be used with each application. Results from the modules, which are based on the module responses and the configured control flags, are passed back through the library to the application. The PAM library provides the framework on which to load the appropriate modules and to manage the stacking process. The PAM library provides a generic structure to which all of the modules can plug in. The PAM framework provides a method for authenticating users with multiple services by using stacking. Depending on the configuration, the user can be prompted for passwords for each authentication method. The order in which the authentication services are used is determined through the PAM configuration file.
| Exam Watch |
With the Pluggable Authentication Module (PAM) framework, we can provide the ability to plug-in technologies for system-entry services. For the exam, you should know that the PAM framework in Solaris lets you plug in new authentication technologies without changing system entry services and configure the use of system entry services for user authentication. |
This section discusses some tasks that might be required to make the PAM framework use a particular security policy. You should be aware of some security issues that are associated with the PAM configuration file.
When you are deciding how best to use PAM in your environment, start by focusing on these issues:
Determine your needs, especially regarding which modules you should select.
Identify the services that need special attention.
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 changing the PAM configuration file:
Use other entries for each module type so that every application does not have to be included.
Make sure to consider the security implications of the binding, 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.
Caution: If the PAM configuration file is misconfigured or the file becomes corrupted, all users might be unable to log in. Since the sulogin command does not use PAM, the root password 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 still have access to correct problems. Test all the commands that might have been affected by your changes. For example, suppose you add a new module to the telnet service. You use the telnet command and verify that your changes make the service behave as expected.
To add a PAM module, you must first become superuser or assume an equivalent role. Next, you need to determine which control flags and other options should be used. Every PAM module implements a specific mechanism. When you set up PAM authentication, you need to specify both the module and the module type, which defines what the module does. More than one module type, such as auth, account, session, or password, can be associated with each module.
The following list describes the Solaris PAM modules, including the filename of the module as well as a description of the purpose of the module. The path of each module is determined by the instruction set that is available in the Solaris release that is installed. The default path to the modules is /usr/lib/security/$ISA. The value for $ISA is sparcv9 for 64-bit modules. For 32-bit modules, $ISA has no value, so the modules are in /usr/lib/security/.
pam_authtok_check.so.1 Provides support for password management. This module performs password strength checks.
pam_authtok_get.so.1 Provides password prompting for authentication.
pam_authtok_store.so.1 Provides support for password management only. This module updates the authentication token for the user.
pam_dhkeys.so.1 Provides support for Diffie-Hellman key management in authentication. This module supports Secure RPC authentication and Secure RPC authentication token management.
pam_dial_auth.so.1 This module uses data that is stored in the /etc/dialups and /etc/d_passwd files for authentication.
pam_krb5.so.1 Provides support for authentication, account management, session management, and password management. Kerberos credentials are used for authentication.
pam_ldap.so.1 Provides support for account and password management. It can also be configured for authentication with an LDAP bind. Data from an LDAP server are used for account management.
pam_passwd_auth.so.1 Provides support for authentication by the passwd command.
pam_rhosts_auth.so.1 Can be used only for authentication. This module uses data that is stored in thê/.rhosts and /etc/host.equiv files through the ruserok() routine. This module is mainly used by the rlogin and rsh commands.
pam_roles.so.1 Provides support for account management only. The user_attr database determines which roles a user can assume.
pam_sample.so.1 Used for testing only. Provides support for authentication, account management, session management, and password management.
pam_smartcard.so.1 Provides support for authentication only.
pam_unix_account.so.1 Provides support for account management. This module retrieves password aging information from the repository that is specified in the nsswitch.conf file. Then the module verifies that the password and the user's account have not expired.
pam_unix_auth.so.1 Provides support for authentication management. The module verifies that the password is correct.
pam_unix_cred.so.1 Provides support for credential management. The module must be stacked with an authentication module.
pam_unix_session.so.1 Provides support for session management.
| Exam Watch |
For the exam, you need to know that PAM module files must be owned by root and must not be writable through group or other permissions. Otherwise, PAM will not load the module. |
For security reasons, these module files must be owned by root and must not be writable through group or other permissions. If the file is not owned by root, PAM does not load the module. Ensure that the ownership and permissions are set so that the module file is owned by root and the permissions are 555. Then edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services. For verification, 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 all of the lines that include rhosts_auth.so.1 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 anŷ/.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.
Become superuser or assume an equivalent role.
Edit the /etc/syslog.conf file to add any of the following entries to log PAM error reports:
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 timestamp, the name of the system that generated the message, and the message. The pamlog file is capable of logging a large amount of information.
Here are some of the key points from the certification objectives in Chapter 12.
The Secure NFS service uses Secure RPC to authenticate users who make requests to the service.
The authentication mechanism (Diffie-Hellman) uses Data Encryption Standard (DES) encryption to encrypt the common key between client and server with a 56-bit key
Normally a user login password is identical to the Secure RPC password, where the login process passes the secret key to the keyserver. If the passwords are different, the user must always run the keylogin command. When the command is included in the user's environment configuration file (such as ~/.login, ~/.cshrc, or ~/.profile), the command runs automatically whenever the user logs in.
The process of generating a conversation key when a user initiates a transaction with a server begins with the keyserver randomly generating a conversation key. The kernel uses the conversation key, plus other material, to encrypt the client's timestamp. Next, the keyserver looks up the server's public key in the public key database and then uses the client's secret key and the server's public key to create a common key. At that point, the keyserver encrypts the conversation key with the common key.
When decrypting a conversation key after the server receives the transmission from the client, the keyserver that is local to the server looks up the client's public key in the public key database. The keyserver then uses the client's public key and the server's secret key to deduce the common key. The kernel uses the common key to decrypt the conversation key, and then calls the keyserver to decrypt the client's timestamp with the decrypted conversation key.
Returning the verifier to the client and authenticating the server starts when the server returns a verifier, including the index ID, which the server records in its credential cache, and the client's timestamp minus 1, which is encrypted by the conversation key. The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what timestamp the client sent. With every transaction after the first transaction, the client returns the index ID to the server in its next transaction. The client also sends another encrypted timestamp. The server sends back the client's timestamp minus 1, which is encrypted by the conversation key.
By requiring authentication for use of mounted NFS file systems, you increase the security of your network.
The Pluggable Authentication Module (PAM) framework lets you plug in new authentication technologies without changing system entry services and configure the use of system entry services (ftp, login, telnet, or rsh, for example) for user authentication.
The PAM software consists of a library, various service modules, and a configuration file. The pam.conf file defines which modules to use and in what order the modules are to be used with each application. The PAM library provides the framework to load the appropriate modules and to manage the stacking process. The PAM library provides a generic structure to which all of the modules can plug in. The PAM framework provides a method for authenticating users with multiple services by using stacking. Depending on the configuration, the user can be prompted for passwords for each authentication method. The order in which the authentication services are used is determined through the PAM configuration file.
If the PAM configuration file is misconfigured or the file becomes corrupted, all users might be unable to log in. Since the sulogin command does not use PAM, the root password would then be required to boot the machine into single-user mode and fix the problem.
For security reasons, PAM module files must be owned by root and must not be writable through group or other permissions. If the file is not owned by root, PAM does not load the module. To load the module, ensure that the ownership and permissions are set so that the module file is owned by root and the permissions are 555. Then edit the PAM configuration file, /etc/pam .conf, and add this module to the appropriate services. Then you must reboot the system before you can verify that the module has been added.
To prevent rhost-style access from remote systems with PAM, remove all of the lines that include rhosts_auth.so.1 from the PAM configuration file. This prevents unauthenticated access to the local system from remote systems. To prevent other unauthenticated access to the ~/.rhosts files, remember to disable the rsh service by removing the service entry from the /etc/inetd.conf file.
Changing the PAM configuration file does not prevent the service from being started.
The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully, because there might be more than one correct answer. Choose all correct answers for each question. Some questions are short-answer questions to ensure you have a good understanding of the material.
|
With regard to Secure RPC to authenticate a host and a user across an NFS mount, where are the public and private keys stored?
|
|
|
|
Normally, a user login password is identical to the Secure RPC password, where the login process passes the secret key to the keyserver. If the passwords are different, what must the user do? |
|
|
|
Each user has a unique public key and secret key; the public key is stored in a public database and the secret key is stored in encrypted form in the same database.
|
|
|
|
Explain how the Secure NFS service authenticates users who make requests to the service. |
|
|
|
What authentication mechanism uses DES encryption to encrypt the common key between client and server with a 56-bit key? |
|
|
|
Explain the process of generating a conversation key when a user initiates a transaction with a server. |
|
|
|
Which of the following commands is used to change an existing key pair?
|
|
|
|
Explain how the client knows that only the server could have sent the verifier? |
|
|
|
Explain the process of decrypting the conversation key when a server receives the transmission from the client. |
|
Answers
|
þ E. All of the answers are correct. Authentication is based on the capability of the sending system to use the common key to encrypt the current time. Then, the receiving system can decrypt and check against its current time. The time on the client and the server must be synchronized. The public keys and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map. NIS+ stores the keys in the cred table. |
|
|
þ Normally a user login password is identical to the Secure RPC password, where the login process passes the secret key to the keyserver. If the passwords are different, the user must always run the keylogin command. When the command is included in the user's environment configuration file (such as~/.login, ~/.cshrc, or ~/.profile), the command runs automatically whenever the user logs in. |
|
|
þ A. True. Sometimes prior to a transaction, the administrator generates a public key and a secret key. Each user has a unique public key and secret key. The public key is stored in a public database. The secret key is stored in encrypted form in the same database. |
|
|
þ The Secure NFS service uses Secure RPC (Remote Procedure Call), which protects remote procedures with an authentication mechanism, to authenticate users who make requests to the service. The authentication mechanism (Diffie-Hellman) uses Data Encryption Standard (DES) encryption to encrypt the common key between client and server with a 56-bit key. |
|
|
þ Diffie-Hellman uses Data Encryption Standard (DES) encryption to encrypt the common key between client and server with a 56-bit key. |
|
|
þ The process of generating a conversation key when a user initiates a transaction with a server begins with the keyserver randomly generating a conversation key. The kernel uses the conversation key, plus other material, to encrypt the client's timestamp. Next the keyserver looks up the server's public key in the public key database and then uses the client's secret key and the server's public key to create a common key. At that point, the keyserver encrypts the conversation key with the common key. |
|
|
þ C. The chkey command changes the key pair. ý A and B are wrong because sometime prior to a transaction, the administrator runs either the newkey or the nisaddcred command to generate a public key and a secret key. |
|
|
þ Returning the verifier to the client and authenticating the server starts when the server returns a verifier that includes the index ID, which the server records in its credential cache, and the client's timestamp minus 1, which is encrypted by the conversation key. The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what timestamp the client sent. With every transaction after the first transaction, the client returns the index ID to the server in its next transaction. The client also sends another encrypted timestamp. The server sends back the client's timestamp minus 1, which is encrypted by the conversation key. |
|
|
þ When decrypting a conversation key after the server receives the transmission from the client, the keyserver that is local to the server looks up the client's public key in the public key database. The keyserver then uses the client's public key and the server's secret key to deduce the common key. The kernel uses the common key to decrypt the conversation key, and then calls the keyserver to decrypt the client's timestamp with the decrypted conversation key. |
|
What does the PAM software consist of? |
|
|
|
Which of the following are true regarding PAM module files?
|
|
|
|
If the PAM configuration file is misconfigured or the file becomes corrupted, all users might be unable to log in. However, since the sulogin command does not use PAM, what should be done to fix the problem? |
|
Answers
|
þ The PAM software consists of a library, various service modules, and a configuration file. The pam.conf file defines which modules to use and in what order the modules are to be used with each application. The PAM library provides the framework to load the appropriate modules and to manage the stacking process. The PAM library provides a generic structure to which all of the modules can plug in. The PAM framework provides a method for authenticating users with multiple services by using stacking. Depending on the configuration, the user can be prompted for passwords for each authentication method. The order in which the authentication services are used is determined through the PAM configuration file. |
|
|
þ D. All of the answers are correct. For security reasons, PAM module files must be owned by root and must not be writable through group or other permissions. To load the module, ensure that the ownership and permissions are set so that the module file is owned by root and the permissions are 555. |
|
|
þ If the PAM configuration file is misconfigured or the file becomes corrupted, all users might be unable to log in. Since the sulogin command does not use PAM, the root password would then be required to boot the machine into single-user mode and fix the problem. |
|
Your favorite customer asked you to come in and, among other things, set up a Diffie-Hellman key for an NIS+ host and user. Assuming all setup and preconfiguration has been completed successfully, what steps would you perform onsite? |
|
Answers
|
To set up a Diffie-Hellman Key for an NIS+ host, which should be done on every host in the NIS+ domain anyway, assume the Primary Administrator role or become superuser. Next, enable the publickey table in the name service by adding the following line to the /etc/nsswitch.conf file: publickey: nisplus At that point, initialize the NIS+ client with the command nisinit -cH hostname where hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client system. Then add the client to the cred table with the commands nisaddcred local and nisaddcred des. Be sure to verify the setup by using the keylogin command. If you are prompted for a password, the procedure has succeeded. To set up a Diffie-Hellman key for an NIS+ user, which should also be done on every user in the NIS+ domain, after assuming superuser, add the user to the cred table on the root master server with the following command: nisaddcred -p unix.UID@domain-name -P username.domain-name. des Note that, in this case, the username.domain-name must end with a dot (.). Again, be sure to verify the setup by logging in as the client and typing the keylogin command. |
|
|
