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
    time.

    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       pam_unix.so
        account  required       pam_unix.so
        password required       pam_unix.so
        session  required       pam_unix.so

    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   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

> `

Next Previous Contents