Security with PAM

PAM,

or Pluggable Authentication Mechanism, provides a powerful and flexible way

to extend the operating system’s built-in authentication systems

transparently, to applications. PAM is the default authentication system

built into every single Linux distribution. It’s always installed (it

controls the logins, so it has to be). Almost all standard Linux apps,

including Samba, and almost all new apps include PAM. So, what’s PAM?

Imagine a server installation

at a high security industrial complex, military, or secret service

establishments. Do you imagine that the mainframes there have a login prompt

flashing all day long waiting for someone to login as "root" with

password "password"?

The security setup you see in

movies such as Mission Impossible may be a bit far-fetched, but is still

closer to reality than you’d think. Authentication mechanisms such as

retinal and fingerprint scanners, smart cards, voice recognition, even

facial recognition, are all possible and in fact, very much a reality today.

While you’re unlikely to need such levels of security on any of your home

or office machines, the technology is fairly common. Even Compaq has

launched machines with fingerprint scanners for authenticating Windows users

in India.

But, what does all this

have to do with PAM?

Imagine what

would happen if every authentication mechanism you used required you to

compile support for it into your applications. While in the world of free,

open-source software, this is quite possible, it’s not necessarily

efficient. What you need is a generic interface to different mechanisms that

basically do the same thing–authenticate users. This is where PAM comes

into the picture. PAM acts as a middle man, whose primary task (among other

things) is to authenticate users, and inform applications of their identity.

PAM was originally developed

by Sun Microsystems. However, most development in recent days is being

carried out by the open-source community. Today almost all Linux

applications include PAM, which means that you can authenticate against a

directory service via LDAP, a Novell Server with NDS, a Windows NT domain

controller, etc.

Applications authenticate

users by calling a standard set of PAM functions. When an application wants

to authenticate a user, it makes a generic call to PAM to handle the

authentication process. Each application has a configuration file associated

with it (usually in/etc/pam.d), specifying which modules to use for

authentication. At this stage, the appropriate PAM module takes over. It

could prompt the user for a password, or perhaps inject her with a complex

protein dye that binds with DNA to generate a unique triple helix pattern,

which can be matched against a database of cloned and radioactive DNA.

Whatever it does, at the end, it passes a simple message to the application

calling it–PAM_SUCCESS or PAM_ FAILURE. That’s all the application needs

to know.

By simply editing their

configuration files, each application can be made to authenticate against

different or even multiple data sources. You can, for example, have modules

that authenticate against the standard Unix password file, as well as

against an LDAP directory (see the article "Setting Up LDAP", page

97 in this issue). Hence, by simply switching the module used in the

configuration file, you can switch which service is used.

Sounds simple?

PAM does a lot of other

things as well. Broadly, you can divide all that PAM can do into four

categories–user authentication, session management, account management,

and password management.

User Authentication is what

we have already discussed–simply determining whether a user is whom he or

she claims to be.

Session management applies to

tasks that are performed at the time of login and logout. This could include

dynamically mounting a user’s home directory, logging information, etc.

Account management includes

restricting the length of time a user can be logged in, what hours he is

permitted to access the system, etc.

To understand what logrotate can do....

To understand what logrotate

can do, first ask yourself what you want to do with your log files. The

table "Planning for a log processing and archiving policy" might

help you to start. The first row lists the processing and reporting to be

done, while the first column lists the files on which the processing is to

be done. Put down the different log files in column 1, tick out the log

processing of your choice, and you can come up with a policy for using

logrotate.

Let me briefly explain what

each column implies. A "yes" on column 2 indicates that you want

to retain the log file as a record, so it’s best kept compressed.

Similarly, a "yes" in column 3 indicates that you merely want to

scan the file, look for the unusual, and then discard it. You might want to

mail this file to yourself or to the relevant administrator. Column 4 says

that you want to discard the file straightaway. In the sysadmin world, this

obviously doesn’t qualify for best practice. Columns 5 and 6

mention the actions you want to perform before and after you do the log

processing. Column 7 is for an e-mail address to which errors during log

processing are to be reported, and column 8 indicates how often you want the

processing to be done. Note that you might want a time threshold with a

granularity of a day or choose to have a file size threshold to rotate the

logs. This table is not exhaustive or mandatory in nature–it’s is merely

an example of how you would go about the policy-making exercise. So, don’t

implement this, as is, as a policy. Evolve one to suit your needs.

If you’re ready with a

table such as the one above, you have a policy. You can now use logrotate to

implement this policy.

The policy is specified using

keywords, as well as with a script-like language comprising keywords

specific to logrotate. The script is intuitive and easy to understand. By

default, most logs are rotated four times, uncompressed, before they’re

removed from the system. This should explain the presence of files with the

extensions .1, .2, .3 and .4 in the /var/log directory. Take the file /var/log/messages

as an example. After a certain time period or after a certain file size is

reached (as specified in /etc/logrotate. conf), this file is renamed to

messages.1 and an empty file called messages is created to take in the new

log input. This is repeated until they’re rotated four times.

Let’s look at a portion of

the configuration from /etc/logrotate.conf from a standard install. The

first line mentions the name of the file for which the policy is laid out.

Notice the intuitive keywords–"monthly" indicates that the

rotation cycle is monthly, "create" specifies the permissions and

ownerships to be used when the old file is moved to another name and an

empty file is created. "Rotate 1" indicates that one rotated

logfile will be retained:

/var/log/wtmp

{ monthly

create 0664

root utmp

rotate 1

}

Here’s a portion of the

file /etc/logrotate.d/apache–the policy for processing apache log files.

The keyword missingok implies that if the log file isn’t found, continue

processing the rest. Notice the command in between the keywords postrotate

and endscript. This command is executed after log processing is done.

Surprisingly, you don’t find any other instructions such as the frequency

of rotation or the number of rotations, as in the previous case. When there’s

no explicit mention made, the definitions in the global configuration file

will apply.

/var/log/httpd/access_log

{

missingok

postrotate

/usr/bin/killall -HUP httpd 2> /dev/null || true

endscript

}

logrotate is typically run

once a day by the cron. If you are logged in as superuser, you would see an

entry similar to the one below in the crontab file:

0 0 * * * /usr/sbin/logrotate

The utility runs every

midnight. You can run it more often if you need to.

A good start towards

minimizing disk storage space would be to uncomment the compress option in

/etc/logrotate. conf, so that all the rotated log files are kept compressed.

Avinash

Shenoy is a systems and network administrator at the NCBS, Bangalore,

and Gopi Garge is a technology

consultant with Exocore Consulting <www.exocore.com>