|
|
This section will discuss good practices for using PAM in a secure manner. It is currently sadly lacking...suggestions are welcome!
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.
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