System Administation: Maximizing System Security, Part 1

A lot of UNIX security is based on passwords, and in this first part of a two-part article, Æleen helps explain many of thei issues involved in setting up and maintaining passwords on Linux systems. Next month's installment will cover other system security issues.
Password Aging

Users don't like to change their passwords, and left to their own devices they will literally never do so. The shadow package includes an optional password aging facility which enables a system administrator to specify how often users must change their passwords. Whether using these features is necessary or not depends on the needs of your site.

Entries in /etc/shadow have the following format:


where the first two fields are the username and encoded password for the account. The other fields relate to account expiration and password aging. [Note that in the shadow file, it cannot be continued across two lines, as we have done here to make it fit in the magazine—ED]

change_date encodes the date of the most recent password change. min_change and max_change indicate the minimum and maximum number of days between password changes, and warn indicates the number of days before a password expires that the user is warned of this fact. inactive specifies how many days after its password has expired that an account is automatically disabled, and expire encodes the date upon which the account itself will expire and be disabled.

Here is a sample entry from /etc/shadow:


User chavez can keep the same password for at most 180 days, and she will be warned 5 days before her password expires. When she does change her password, she must keep the new one for at least 7 days. If she doesn't use her account for 21 days, it will be automatically disabled. No expiration date is set for user chavez's account.

Once /etc/shadow is installed, it can be edited directly. However, the shadow package also provides tools for manipulating entries within it. Its version of the passwd command updates passwords within the shadow password file, and the command also has additional options for modifying the other password settings. For example, the following command changes the minimum password lifetime to 2 days, the maximum password lifetime to 1 year, the warning period to 3 days, and the inactive period to two months for user chavez:

# passwd -n 2 -x 365 -w 3 -i 60 chavez

If you wanted to remove all aging controls from an account, use this combination of options:

# passwd -n 0 -x 99999 -i -1 angela

These are the default values (along with a warning period of 14 days, which is irrelevant when passwords essentially never expire).

Account expiration dates are set with the usermod command. The following command sets the account expiration date to January 1, 1999 for user chavez:

# usermod -e 1/1/1999 chavez

Note that the useradd and usermod commands may also be used to create user accounts and specify or alter these and other account settings.

passwd's -l and -uoptions may be used to manually lock (i.e., prevent logins) and unlock an account respectively:

# passwd -l badboy

Finally, the chage -d command may be used to force a user to change his password at his next login; this option sets the date of the last password change field. It may be used to force a password change at a user's next login, provided that a maximum password lifetime is also set. Here is a simple script which accomplishes this:

# force_change username -- run as root
chage -l $1 >& /dev/null
if ($status == 1) then
   echo force_change: invalid user "\$1\"
   exit 1
set max=`grep ^$1\: /etc/shadow | \
  awk -F: '{print $5}'`
chage -d `date +%D` $1
set today=`grep ^$1\: /etc/shadow | \
  awk -F: '{print $3}'`
set yest=`expr $today - 1`
if ($max >= $yest) set max=`expr $yest - 1`
set date=`expr $yest - $max`
chage -M $max -I 2 -W 7 -d $date $1

The script extracts the current maximum password lifetime setting, sets the password change date to today, and then extracts the equivalent integer value (the number of days since 1/1/1970). It then sets the password change date to yesterday, reducing the maximum lifetime if necessary so that a password expiration is possible on that date. It also sets the inactivity period to 2 days and the warning period to 1 week.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot