"Pluggable Authentication Modules for Linux is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users." Straight from the PAM documentation, I don't think I could have said it any better. But what does this actually mean? For example; take the program “login”, when a user connects to a tty (via a serial port or over the network) a program answers the call (getty for serial lines, usually telnet or SSH for network connections) and starts up the “login” program, “login” then typically requests a username, followed by a password, which it checks against the /etc/passwd file. This is all fine and dandy until you have a spiffy new digital card authentication system and want to use it. Well you will have to recompile login (and any other apps that will do authentication via the new method) so they support the new system. As you can imagine this is quite laborious and prone to errors.
PAM introduces a layer of middleware between the application and the actual authentication mechanism. Once a program is PAM'ified, any authentication methods PAM supports will be usable by the program. In addition to this PAM can handle account, and session data which is something normal authentication mechanisms don't do very well. For example using PAM you can easily disallow login access by normal users between 6pm and 6am, and when they do login you can have them authenticate via a retinal scanner. By default Red Hat systems are PAM aware, and newer versions of Debian are as well (see bellow for a table of PAM’ified systems). Thus on a system with PAM support all I have to do to implement shadow passwords is convert the password and group files; and possibly add one or two lines to some PAM config files (if they weren't already added). Essentially, PAM gives you a great deal of flexibility when handling user authentication, and will support other features in the future such as digital signatures with the only requirement being a PAM module or two to handle it. This kind of flexibility will be required if Linux is to be an enterprise-class operating system. Distributions that do not ship as "PAM-aware" can be made so but it requires a lot of effort (you must recompile all your programs with PAM support, install PAM, etc), it is probably easier to switch straight to a PAM'ified distribution if this will be a requirement. PAM usually comes with complete documentation, and if you are looking for a good overview you should visit: http://www.sun.com/software/solaris/pam/.
Other benefits of a PAM aware system is that you can now make use of an NT domain to do your user authentication, meaning you can tie Linux workstations into an existing Microsoft based network without having to say buy NIS / NIS+ for NT and go through the hassle of installing that.
Distribution | Version | PAM Support |
Red Hat | 5.0, 5.1, 5.2, 6.0 | Completely |
Debian | 2.1 | Yes |
Caldera | 1.3, 2.2 | Completely |
TurboLinux | 3.6 | Completely |
SuSE | 6.2 | Yes |
There are more distributions that support PAM and are not listed here, so please tell me about them.
http://www.jdimedia.nl/igmar/pam/
NIS and NIS+ (formally known as “yellow pages”) stands for Network Information Service. Essentially NIS and NIS+ provide a means to distribute password files, group files, and other configuration files across many machines, providing account and password synchronization (among other services). NIS+ is essentially NIS with several enhancements (mostly security related), otherwise they are very similar.
To use NIS you set up a master NIS server that will contain the records and allow them to be changed (add users, etc), this server can distribute the records to slave NIS machines that contain a read only copy of the records (but they can be promoted to master and set read/write if something bad happens). Clients of the NIS network essentially request portions of the information and copy it directly into their configuration files (such as /etc/passwd), thus making them accessible locally. Using NIS you can provide several thousand workstations and servers with identical sets of usernames, user information, passwords and the like, significantly reducing administration nightmares.
However this is part of the problem: in sharing this information you make it accessible to attackers. NIS+ attempts to resolve this issue however, but NIS+ is an utter nightmare to set up.
An alternative strategy would be to use some sort of VPN (like FreeS/WAN, doesn’t it seem to solve almost any problem?) and encrypt the data before it gets onto the network. There is an NIS / NIS+ HOWTO at: http://metalab.unc.edu/LDP/HOWTO/NIS-HOWTO.html, and O’Reilly has an excellent book on the subject, "Managing NFS and NIS". NIS / NIS+ runs over RPC which uses port 111, both tcp and udp. This should definitely be blocked at your network border, but will not totally protect NIS / NIS+. Because NIS and NIS+ are RPC based services they tend to use higher port numbers (i.e. above 1024) in a somewhat random fashion, making firewalling of it rather difficult. The best solutions is to place your NIS server(s) on an internal network that is blocked completely from talking to the Internet, inbound and outbound. There is also an excellent paper on securing NIS available from: http://www.eng.auburn.edu/users/doug/nis.html.
ipfwadm -I -a accept -P udp -S 10.0.0.0/8 -D 0.0.0.0/0 111
ipfwadm -I -a accept -P udp -S some.trusted.host -D 0.0.0.0/0 111
ipfwadm -I -a deny -P udp -S 0.0.0.0/0 -D 0.0.0.0/0 111
or
ipchains -A input -p udp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 111
ipchains -A input -p udp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 111
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 111
SRP is a relative newcomer, however it has several advantages over some of the older programs. SRP is free for non commercial use and does not use encryption per se to secure the data, so exporting it outside of the US isn’t as much of a problem. SRP uses one way hashes and provides authentication of both parties. The disadvantage is that SRP only encrypts the login (username and password) so any data transferred (such as the telnet session or ftp sites) are vulnerable. You can get SRP from: http://srp.stanford.edu/srp/. SRP currently has Telnet and FTP support (for windows as well) although SRP enabling other protocols is relatively straightforward.
Kerberos is a modern network authentication system based on the idea of handing a user a ticket once they have authenticated to the Kerberos server (similar to NT’s use of tokens). Kerberos is available from: http://web.mit.edu/kerberos/www/. The Kerberos FAQ is available at: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html. Kerberos is appropriate for large installations as it scales better and is more secure then NIS / NIS+. Kerberizing programs such as telnet, imap and pop can be achieved with some effort, Windows clients with Kerberos support are harder to find however.
![]() Written by Kurt Seifried |