Unix Host Security: Hacks 11-20 - Control Login Access with PAM Hack #17 (Page 7 of 10 )
Seize fine-grained control of when and where your users can access your system.
In traditional Unix authentication there is not much granularity available in limiting a user’s ability to log in. For example, how would you limit the hosts that users can come from when logging into your servers? Your first thought might be to set up TCP wrappers or possibly firewall rules [Hack #33] and [Hack #34]. But what if you wanted to allow some users to log in from a specific host, but disallow others from logging in from it? Or what if you wanted to prevent some users from logging in at certain times of the day because of daily maintenance, but allow others (i.e., administrators) to log in at any time they wish? To get this working with every service that might be running on your system, you would traditionally have to patch each of them to support this new functionality. This is where PAM enters the picture.
PAM, or pluggable authentication modules, allows for just this sort of functionality (and more) without the need to patch all of your services. PAM has been available for quite some time under Linux, FreeBSD, and Solaris, and is now a standard component of the traditional authentication facilities on these platforms. Many services that need to use some sort of authentication now support PAM.
Modules are configured for services in a stack, with the authentication process proceeding from top to bottom as the access checks complete successfully. You can build a custom stack for any service by creating a file in /etc/ pam.d with the same name as the service. If you need even more granularity, an entire stack of modules can be included by using the pam_stack module. This allows you to specify another external file containing a stack. If a service does not have its own configuration file in /etc/pam.d, it will default to using the stack specified in /etc/pam.d/other.
When configuring a service for use with PAM, there are several types of entries available. These types allow one to specify whether a module provides authentication, access control, password change control, or session setup and teardown. Right now, we are interested in only one of the types: the account type. This entry type allows you to specify modules that will control access to accounts that have been authenticated. In addition to the service-specific configuration files, some modules have extended configuration information that can be specified in files within the /etc/security directory. For this hack, we’ll mainly use two of the most useful modules of this type, pam_access and pam_time.
The pam_access module allows one to limit where a user or group of users may log in from. To make use of it, you’ll first need to configure the service you wish to use the module with. You can do this by editing the service’s PAM config file in /etc/pam.d.
Here’s an example of what /etc/pam.d/login might look like under Red Hat 9:
#%PAM-1.0
auth required pam_securetty.so
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so
Notice the use of the pam_stack module—it includes the stack contained within the system-auth file. Let’s see what’s inside /etc/pam.d/system-auth:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok
md5 shadow
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
To add the pam_access module to the login service, you could add another account entry to the login configuration file, which would, of course, just enable the module for the login service. Alternatively, you could add the module to the system-auth file, which would enable it for most of the PAMaware services on the system.
To add pam_access to the login service (or any other service for that matter), simply add a line like this to the service’s configuration file after any preexisting account entries:
account required pam_access.so
Now that we’ve enabled the pam_access module for our services, we can edit /etc/security/access.conf to control how the module behaves. Each entry in the file can specify multiple users, groups, and hostnames to which the entry applies, and specify whether it’s allowing or disallowing remote or local access. When pam_access is invoked by an entry in a service configuration file, it will look through the lines of access.conf and stop at the first match it finds. Thus, if you want to create default entries to fall back on, you’ll want to put the more specific entries first, with the general entries following them.
The general form of an entry in access.conf is:
permission : users : origins
where permission can be either a + or -. This denotes whether the rule grants or denies access, respectively.
The users portion allows you to specify a list of users or groups, separated by whitespace. In addition to simply listing users in this portion of the entry, you can use the form user@host, where host is the local hostname of the machine being logged into. This allows you to use a single configuration file across multiple machines, but still specify rules pertaining to specific machines. The origins portion is compared against the origin of the access attempt. Hostnames can be used for remote origins, and the special LOCAL keyword can be used for local access. Instead of explicitly specifying users, groups, or origins, you can also use the ALL and EXCEPT keywords to perform set operations on any of the lists.
Here’s a simple example of locking out the user andrew (Eep! That’s me!) from a host named colossus:
- : andrew : colossus
Note that if a group that shares its name with a user is specified, the module will interpret the rule as applying to both the user and the group.
Now that we’ve covered how to limit where a user may log in from and how to set up a PAM module, let’s take a look at how to limit what time a user may log in by using the pam_time module. To configure this module, you need to edit /etc/security/time.conf. The format for the entries in this file are a little more flexible than that of access.conf, thanks to the availability of the NOT (!), AND (&), and OR (|) operators.
The general form for an entry in time.conf is:
services;devices;users;times
The services portion of the entry specifies what PAM-enabled service will be regulated. You can usually get a full list of the available services by looking at the contents of your /etc/pam.d directory.
For instance, here’s the contents of /etc/pam.d on a Red Hat Linux system:
$ ls -1 /etc/pam.d
authconfig
chfn
chsh
halt
internet-druid
kbdrate
login
neat
other
passwd
poweroff
ppp
reboot
redhat-config-mouse
redhat-config-network
redhat-config-network-cmd
redhat-config-network-druid
rhn_register
setup
smtp
sshd
su
sudo
system-auth
up2date
up2date-config
up2date-nox
vlock
To set up pam_time for use with any of these services, you’ll need to add a line like this to the file in /etc/pam.d that corresponds to the service that you want to regulate:
account required /lib/security/$ISA/pam_time.so
The devices portion specifies the terminal device that the service is being accessed from. For console logins, you can use !ttyp*, which specifies all TTY devices except for pseudo TTYs. If you want the entry to only affect remote logins, then use ttyp*. You can restrict it to all users (console, remote, and X11) by using tty*.
For the users portion of the entry, you can specify a single user or a list of users by separating each one with a | character. The times portion is used to specify the times that the rule will apply. Each time range is specified with a combination of two character abbreviations, which denote the days that the rule will apply, followed with a range of hours for that day. The abbreviations for the days of the week are Mo, Tu, We, Th, Fr, Sa, and Su. For convenience you can use Wk to specify weekdays and Wd to specify the weekend. In addition, you can use Al to specify every day of the week. These last three basically expand to the set of days that compose each time period. This is important to remember, since repeated days are subtracted from the set of days that the rule will apply to (e.g., WkSu would effectively be just Sa). The range of hours is simply specified as two 24-hour times, minus the colons, separated by a dash (e.g., 0630-1345 is 6:30 A.M. to 1:45 P.M.).
If you wanted to disallow access to the user andrew from the local console on weekends and during the week after hours, you could use an entry like this:
system-auth;!ttyp*;andrew;Wk1700-0800|Wd0000-2400
Or perhaps you want to limit remote logins through SSH during a system maintenance window lasting from 7 P.M. Friday to 7 A.M. Saturday, but want to allow a sysadmin to log in:
sshd;ttyp*;!andrew;Fr1900-0700
As you can see, there’s a lot of flexibility for creating entries, thanks to the logical Boolean operators that are available. Just make sure that you remember to configure the service file in /etc/pam.d for use with pam_time when you create entries in /etc/security/time.conf.
 | If you've enjoyed what you've seen here, or to get more information, click on the "Buy the book!" graphic. Pick up a copy today!
Visit the O'Reilly Network http://www.oreillynet.com for more online content. |
Next: Restricted Shell Environments Hack #18 >>
More Security Articles
More By O'Reilly Media
