How this document came to be

When trying to add a number of (mostly unnecessary :) network services to my existing home network, I kept running into the problem of authentication, so I decided to figure out how authentication works on linux systems, write a HOWTO, and call it my senior project. I hope this document helps you understand this often-forgotten, but very important, aspect of system administration.

New versions

When I get my domain up running properly, you'll be able to find the newest version of this document there. Until then, http://www.linuxdoc.org/ will have to suffice.

Feedback

Comments, corrections, suggestions, flames, and flying saucer sightings can be sent to petehern@yahoo.com.

Version History

v0.1 (May 13, 2000) first version (not released).

v0.3 (May 14, 2000) revised (not released).

v0.5 (May 15, 2000) added section on securing pam, added resources section (not released).

v0.7 (May 15, 2000) revised; ready for release.

Copyrights and Trademarks

(c) 2000 Peter Hernberg

This manual may be reproduced in whole or in part, without fee, subject to the following restrictions:

• The copyright notice above and this permission notice must be preserved complete on all complete or partial copies

• Any translation or derived work must be approved by the author in writing before distribution.

• If you distribute this work in part, instructions for obtaining the complete version of this manual must be included, and a means for obtaining a complete version provided.

• Small portions may be reproduced as illustrations for reviews or quotes in other works without this permission notice if proper citation is given. Exceptions to these rules may be granted for academic purposes: Write to the author and ask. These restrictions are here to protect us as authors, not to restrict you as learners and educators. Any source code (aside from the SGML this document was written in) in this document is placed under the GNU General Public License, available via anonymous FTP from the GNU archive.

Acknowledgements and Thanks

Thanks to my family for putting up with me for 18 years. Thanks to the Debian folks for making such a sweet distro for me to play with. Thanks to CGR for paying me to be a geek. Thanks to Sandy Harris for his helpful suggestions. Finally, I'd like thank the makers of ramen noodles, because I don't know how I'd live without them.

Assumptions about the reader

For the purpose of this document, it is assumed that the reader is comfortably with executing commands at the command line and editing text configuration files.

/etc/passwd

On almost all linux distributions (and commercial *nixes as well), user information is stored in /etc/passwd, a text file which contains the user's login, their encrypted password, a unique numerical user id (called the uid), a numerical group id (called the gid), an optional comment field (usually containing such items as their real name, phone number, etc.), their home directory, and their preferred shell. A typical entry in /etc/passwd looks something like this:

  pete:K3xcO1Qnx8LFN:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
  

As you can see, it's pretty straight-forward. Each entry contains the six fields I described above, with each field separated by a colon. If this were as complex as user authentication got, there would be no need for this HOWTO.

Shadow passwords

Looking at your /etc/passwd, it's likely that you actually saw something like this:

  pete:x:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
  

Where did the encrypted password go? Before I tell you where it went, a bit explanation is required.

The /etc/passwd file, which contains information about all users, including their encrypted password, is readable by all users, making it possible for any user to get the encrypted password of everyone on the system. Though the passwords are encrypted, password-cracking programs are widely available. To combat this growing security threat, shadow passwords were developed.

When a system has shadow passwords enabled, the password field in /etc/passwd is replaced by an "x" and the user's real encrypted password is stored in /etc/shadow. Because /etc/shadow is only readable by the root user, malicious users cannot crack their fellow users' passwords. Each entry in /etc/shadow contains the user's login, their encrypted password, and a number of fields relating to password expiration. A typical entry looks like this:

    pete:/3GJllg1o4152:11009:0:99999:7:::
   

/etc/group and /etc/gshadow

Group information is stored in /etc/group. The format is similar to that of /etc/passwd, with the entries containing fields for the group name, password, numerical id (gid), and a comma-separated list of group members. An entry in /etc/group looks like this:

   pasta:x:103:spagetti,fettucini,linguine,vermicelli
  

As you can see from the "x" in the password field, group passwords can be shadowed as well. Although groups almost never have their own passwords, it is worth noting that shadowed group password information is stored in /etc/gshadow.

MD5 encrypted passwords

Traditionally, unix passwords were encrypted with the standard crypt() function. (For more information on the crypt() function, see the crypt(3) manpage.) As computers grew faster, passwords encrypted with this function became easier to crack. As the internet emerged, tools for distributed the task of password-cracking across multiple hosts became available. Many newer distributions ship with the option of encrypting passwords with the stronger MD5 hash algorithm. (For more information on the MD5 hash algorithm, consult RFC 1321.) While MD5 passwords will not eliminate the threat of password cracking, they will make cracking your passwords much more difficult.

Sifting through the mess

As you can see, there are a number of different ways user authentication information can be stored on your system (shadow passwords without MD5 encryption, /etc/passwd passwords with MD5 encryption, etc.). How do programs like login and su know how to verify your password? Worse yet, what if you wanted to change the way passwords are stored on your system? How will programs that need your password know that passwords are stored differently? PAM is the answer.

Why

Back in the good old days of linux, if a program, such as su, passwd, login, or xlock, needed to authenticate a user, it would simply read the necessary information from /etc/passwd. If it needed to change the users' password, it would simply edit /etc/passwd. This simple but clumsy method presented numerous problems for system administrators and application developers. As MD5 and shadow passwords became increasingly popular, each program requiring user authentication had to know how to get the proper information when dealing with a number of different schemes. If you wanted to change your user authentication scheme, all these programs had to be recompiled. PAM eliminates this mess by enabling programs to transparently authenticate users, regardless of how user information is stored.

What

Quoting from the Linux-PAM System Administrator's Guide: "It is the purpose of the Linux-PAM project to separate the development of privilege granting software from the development of secure and appropriate authentication schemes. This is accomplished by providing a library of functions that an application may use to request that a user be authenticated." With PAM, it doesn't matter whether your password is stored in /etc/passwd or on a server in Hong Kong. When a program needs to authenticate a user, PAM provides a library containing the functions for the proper authentication scheme. Because this library is loaded dynamically, changing authentication schemes can be done by simply editing a configuration file.

Flexibility is one of PAM's greatest strengths. PAM can be configured to deny certain programs the right to authenticate users, to only allow certain users to be authenticated, to warn when certain programs attempt to authenticate, or even to deprive all users of login privileges. PAM's modular design gives you complete control over how users are authenticated.

How

Enough talk, let's dig in.

  ~$ cd /etc/pam.d
  /etc/pam.d/$ ls
  chfn	chsh	login	other	passwd	su	xlock
  /etc/pam.d/$ 
  

  /etc/pam.d/$ cat login
  # PAM configuration for login
  auth       requisite  pam_securetty.so
  auth       required   pam_nologin.so
  auth       required   pam_env.so
  auth       required   pam_unix.so nulok
  account    required   pam_unix.so
  session    required   pam_unix.so
  session    optional   pam_lastlog.so
  password   required   pam_unix.so nullok obscure min=4 max=8
  

  type  control  module-path  module-arguments
  

    auth       required   pam_unix.so nulok
    

    login	auth       required   pam_unix.so nulok
    

Getting more information

For more information on configuring PAM and complete PAM module reference, consult the Linux-PAM System Administrator's Guide. This guide serves as a thorough and up-to-date reference on PAM configuration.

A strong /etc/pam.d/other

All of the files in /etc/pam.d/ contain the configuration for a particular service. The notable exception to this rule is the /etc/pam.d/other file. This file contains the configuration for any services which do not have their own configuration file. For example, is the (imaginary) xyz service attempted authentication PAM would look for a /etc/pam.d/xyz file. Not finding one, authentication for xyz would be determined by the /etc/pam.d/other file. Since /etc/pam.d/other is the configuration to which PAM services fallback, it is important that it is secure. We will discuss two secure configurations of /etc/pam.d/other, one which is quite nearly paranoid and which is gentler.

    auth	required	pam_deny.so 
    auth	required	pam_warn.so 
    account	required	pam_deny.so 
    account	required	pam_warn.so 
    password	required	pam_deny.so 
    password	required	pam_warn.so 
    session	required	pam_deny.so 
    session	required	pam_warn.so
    

    auth	required	pam_unix.so 
    auth	required	pam_warn.so 
    account	required	pam_unix.so 
    account	required	pam_warn.so 
    password	required	pam_deny.so 
    password	required	pam_warn.so 
    session	required	pam_unix.so 
    session	required	pam_warn.so
    

Disabling logins for user with null passwords

On most linux systems, there a number of "dummy" user accounts, used to assign privileges to certain system services like ftp, webservers, and mail gateways. Having these accounts allows your system to be more secure, because if these services are compromised, an attacker will only gain the limited privileges available to the dummy account, rather than the full privileges of a service running as root. However, allowing these dummy account login privileges is a security risk, as they usually have blank (null) passwords. The configuration option that enables null passwords is the "nullok" module-argument. You'll want remove this argument from any modules of 'auth' type for services that allow login. This is usually the login service, may also include services like rlogin and ssh. Hence, the following line in /etc/pam.d/login:

   auth		required	pam_unix.so	nullok
   

should be changed to:

   auth		required	pam_unix.so
   

Disable unused services

Looking at the files in /etc/pam.d/, you'll probably see configuration files for a number of programs you don't use and maybe even a few you've never heard of. Although allowing authentication to these services probably won't open any huge security holes, you're better off denying them authentication. The best way to disable PAM authentication for these programs is to rename these files. Not finding the file named after the service requesting authentication, PAM will fallback to the (hopefully) very secure /etc/pam.d/other. If you later find that you need one of these programs, you can simply rename the file to its original name and everything will work as it was intended.

Password-cracking tools

While password-cracking tools can be by attackers used to compromise a system, they can also be used by system administrators as proactive tool to ensure the strength of passwords on their system. The two most commonly used password-cracking tools are "crack" and "John the Ripper". Crack is probably included in your facorite distribution. John the Ripper can be obtained from http://www.false.com/security/john/index.html. Run the tools against your password database and you'll probably be surprised with what they come up with.

Additionally, there is a PAM module which utilizes the crack library to check the strength of a users password whenever it changed. When this module is installed, the user can only change their password to one which meets the minimum password strength.

Shadow and MD5 passwords

As was discussed in the first section of this document, Shadow and MD5 passwords can make your system more secure. During the installation procedure, most modern distributions will ask whether you want to install MD5 and/or Shadow passwords. Unless you have a good reason not to, you should enable these. The process of converting from non-shadowed/non-MD5 passwords is a complicated process, and is beyond the scope of this document. The Shadow Password HOWTO is outdated, but it might be of some help.

Apache + mod_auth_pam

As our example, we'll install and configure mod_auth_pam, an Apache module that allows you to use authenticate users of your webserver using PAM. For the purpose of this example, I'll assume you have apache installed. If it's not installed already you should be able find installation packages from your distributor.

   ~# tar xzf mod_auth_pam.tar.gz
   ~# cd mod_auth_pam-1.0a
   ~/mod_auth_pam-1.0a# make
   ~/mod_auth_pam-1.0a# make install
   

   ~# /etc/init.d/apache restart
   

     auth	required	pam_unix.so
     

     auth	required	pam_unix.so
     account	required	pam_unix.so
     

    <Directory /var/www/family>
    AuthPAM_Enabled on
    AllowOverride None
    AuthName "Family Secrets"
    AuthType "basic"
    require group family
    </Directory>
    

PAM

• Linux-PAM System Administrator's Guide

• Linux-PAM Module Writer's Manual

• Linux-PAM Application Developer's Manual

General Security

• linuxsecurity.com

• securitywatch.com

• Security HOWTO

• Packetstorm

Offline Documentation

A lot of information can be gathered from your system's manual pages. The following are some manpages relating to user authentication. The number in parentheses refers to the manpage section. To view the passwd(5) manpage, you would enter man 5 passwd.

• passwd(5)

• crypt(3)

• pam.d(5)

• group(5)

• shadow(5)