Home > Articles > Programming > Android

Using pam_rhosts_auth

The evils of the Berkeley r-commands were extolled in Chapter 1, where we looked at some of the vulnerabilities associated with these utilities. In Chapter 11, we will look at completely replacing the Berkeley r-commands.

Table 5.14 Arguments to pam_rhosts_auth

Arguments

Description

debug

Generates more output to syslog.

no_hosts_equiv

Disables /etc/hosts.equiv functionality.

no_rhosts

Ignores $HOME/.rhosts files.

no_warn

Suppresses warning messages to the user. As of this writing, the module generates no warning messages anyway!

privategroup

Normally, if a $HOME/.rhosts file is writable by other than the owner, this module will assume the file has been compromised and return a failure. This argument will allow the $HOME/.rhosts file to be writable by the owner and the owner's group if the owner's group is a UPG.* This will be true if the UID and GID are identical and greater than 500.

promiscuous

The default behavior of this module is to ignore + wildcards in $HOME/.rhosts and /etc/hosts.equiv files. This argument will allow such wildcards. Use of this argument cannot be advised. See Chapter 3.

suppress

Suppresses error messaging to syslog.

Here we will look at using pam_rhosts_auth to limit or altogether eliminate trusted hosts.

This module is an auth-type module only. It accepts the arguments listed in Table 5.14. Configuration of this module is highly system specific and site dependent. Allowing this functionality internally may be acceptable and, in the eyes of your users, necessary. On certain systems, such as restricted servers, systems within perimeter networks, 5 and firewalls, $HOME/.rhosts and etc/hosts.equiv files should be strictly regulated if not completely forbidden.

You will want to place entries for this module in /etc/pam.d/rsh and etc/pam.d/rlogin and any other PAM-aware service that uses these files. To affect the traditional implementation (allow trusted hosts), use an entry such as

          auth sufficient /lib/security/pam_rhosts_auth.so

at the top of the auth stack (minimally, this module must appear before the module in the stack that prompts the user for his or her password) in /etc/pam.d/rsh and /etc/pam.d/rlogin. A more restrictive entry could be placed in these same files on sensitive systems. For example, an entry of the form

          auth required /lib/security/pam_rhosts_auth.so no_rhosts

at the top of the auth stack (or, again, before a module generating a password prompt) would completely disable the use of $HOME/.rhosts files, but would preserve the use of /etc/hosts.equiv (which does not apply to root).

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.