Next Previous Contents

5. Security issues of Linux-PAM

This section will discuss good practices for using PAM in a secure manner. It is currently sadly lacking...suggestions are welcome!

5.1 If something goes wrong

Linux-PAM has the potential to seriously change the security of your system. You can choose to have no security or absolute security (no access permitted). In general, Linux-PAM errs towards the latter. Any number of configuration errors can dissable access to your system partially, or completely.

The most dramatic problem that is likely to be encountered when configuring Linux-PAM is that of deleting the configuration file(s): /etc/pam.d/* and/or /etc/pam.conf. This will lock you out of your own system!

To recover, your best bet is to reboot the system in single user mode and set about correcting things from there. The following has been adapted from a life-saving email on the subject from David Wood:

> What the hell do I do now?

OK, don't panic. The first thing you have to realize is that
this happens to 50% of users who ever do anything with PAM.
It happened here, not once, not twice, but three times, all
different, and in the end, the solution was the same every

First, I hope you installed LILO with a delay. If you can,
reboot, hit shift or tab or something and type:

    LILO boot: linux single

(Replace 'linux' with 'name-of-your-normal-linux-image').
This will let you in without logging in.  Ever wondered how
easy it is to break into a linux machine from the console?
Now you know.

If you can't do that, then get yourself a bootkernel floppy
and a root disk a-la slackware's rescue.gz.  (Red Hat's
installation disks can be used in this mode too.)

In either case, the point is to get back your root prompt.

Second, I'm going to assume that you haven't completely
nuked your pam installation - just your configuration files.
Here's how you make your configs nice again:

    cd /etc
    mv pam.conf pam.conf.orig
    mv pam.d pam.d.orig
    mkdir pam.d
    cd pam.d

and then use vi to create a file called "other" in this
directory.  It should contain the following four lines:

    auth     required
    account  required
    password required
    session  required

Now you have the simplest possible PAM configuration that
will work the way you're used to.  Everything should
magically start to work again.  Try it out by hitting ALT-F2
and logging in on another virtual console.  If it doesn't
work, you have bigger problems, or you've mistyped
something.  One of the wonders of this system (seriously,
perhaps) is that if you mistype anything in the conf files,
you usually get no error reporting of any kind on the
console - just some entries in the log file.  So look there!
(Try 'tail /var/log/messages'.)

From here you can go back and get a real configuration
going, hopefully after you've tested it first on a machine
you don't care about screwing up.  :/

Some pointers (to make everything "right" with Red Hat...):

    Install the newest pam, pamconfig, and pwdb from the
    redhat current directory, and do it all on the same
    command line with rpm...

        rpm -Uvh [maybe --force too] pam-* pamconfig-* pwdb-*

    Then make sure you install (or reinstall) the newest
    version of libc, util-linux, wuftp, and NetKit. For
    kicks you might try installing the newest versions of
    the affected x apps, like xlock, but I haven't gotten
    those to work at all yet.

5.2 Avoid having a weak `other' configuration

It is not a good thing to have a weak default (OTHER) entry. This service is the default configuration for all PAM aware applications and if it is weak, your system is likely to be vulnerable to attack.

Here is a sample "other" configuration file. The pam_deny module will deny access and the pam_warn module will send a syslog message to auth.notice:

# The PAM configuration file for the `other' service 
auth      required 
auth      required 
account   required 
account   required 
password  required 
password  required 
session   required 
session   required

Next Previous Contents