Using
Unknown Passwords
Ed Schaefer and John Spurgeon
Often, several administrators have root privileges on a system.
In cases where people are allowed to log in as root or use su to
become root, more than one person needs to know root's password.
Sharing root's password presents challenges and raises security
concerns. How do you know who did what as root? Who gets to change
root's password, and how is information communicated? How do you
revoke or change someone's access to a system when they know root's
password?
Instead of sharing root's password, consider setting root's password
to a value that nobody knows.
With sudo, root privileges can be granted to individuals even
though root's password is unknown. (This technique can be used to
manage passwords for any privileged account -- not just root.) A
carefully crafted program can automatically generate a strong password.
Finally, an entry in root's crontab file can periodically set root's
password to a random value.
This column describes the sudo setup; a Korn shell script, genpass,
that generates a random password; and two methods for root to automatically
set the password.
Granting Root Privileges with sudo
Sudo is a free utility that allows a user to run commands as root
or any other user without having to know another user's password.
Below is a simple /etc/sudoers file that gives tom, dick, and
harriet the ability to become root without needing to know root's
password:
Cmnd_Alias BECOME_ROOT = /sbin/su - root
User_Alias SUPER_USERS = tom, dick, harriet
SUPER_USERS ALL = BECOME_ROOT
For members to log in as root, they must execute this command:
sudo su -
If this seems too complicated, you could create an alias such as:
become='sudo su -'
Now, all the user has to type to become root is:
become root
Although sudo setup is outside the scope of this article, it is worth
noting that you should always edit the /etc/sudoers file using visudo;
this is analogous to using vipw to edit /etc/password.
Generating Strong Passwords
Designing a program to generate strong, secure passwords can be
tricky. How many different passwords can the program generate? If
the password generator can only generate a million different passwords,
then it may not take a computer very long to try them all.
Are all of the passwords that the program generates strong passwords?
In other words, are the passwords long enough and do they contain
a good mix of lowercase, uppercase, digits, and special characters?
How difficult is it for someone to guess or control the passwords
that the program generates? Many password generators rely on a pseudo-random
number generator of some sort that in turn requires an initializing
seed. If the seed can be controlled or easily guessed, then the
resulting password probably isn't secure.
If a person needs to remember the password, how easy is it to
memorize? Fortunately, this isn't a concern with unknown passwords.
Generating Random Passwords
Our solution for generating random passwords is the Korn shell
script genpass (Listing 1), which by default returns an eight-character
password. The script creates four arrays containing uppercase characters,
lowercase characters, the digits, and the special characters. The
password is built by a loop iterating once for each character in
the password.
With each iteration, a call to the Korn shell RANDOM number generator
determines which array is used to generate a character. Once the
array is chosen, another call to RANDOM generates an index into
the chosen array determining the particular character of the password.
We seed random by creating a string based on the output of the
vmstat command, the ps command, and the contents of
the shadow file. We use the first eight characters of the check
sum of these strings.
Setting Passwords Automatically
Using setpass
After generating the random password, we still need root to automatically
set the password. In a Solaris environment, Higgin's setpass utility
allows the root user to assign a password to a user:
The following entry in root's cron resets the root password each
minute:
* * * * * /usr/sbin/setpass -d -n -f /dev/null -p '/usr/sbin/genpass' root
The setpass utility is not part of the Solaris distribution, but the
"C" source is available from UnixReview.com (see Resources).
Originally, Higgins didn't allow setpass to change root's password.
Since our process requires this ability, we eliminated the following
if statement:
if ((strcmp("root", uname)) == 0) {
fprintf(stderr, "%s can't change root's password\n", pgm);
continue;
}
Finally, since cron uses the Bourne shell, note the use of back tics
for command substitution.
Using autopasswd
Setpass is a Solaris-specific program. Expect provides a more
portable solution. Expect lets you automate the dialogue with interactive
programs such as passwd. Expect includes a sample program called
autopasswd (Listing 2) that can also be used to set passwords.
The following entry in root's cron changes the root password every
minute:
* * * * * /usr/sbin/autopasswd root '/usr/sbin/genpass'
Conclusion
Admittedly, this is a novel, controversial topic and requires
a different mind set, but here are some of the benefits:
- We no longer need to communicate with other users when the
root password changes, and that's a good thing.
- It's easy to disable accounts for people who knew the root
password. Don't change the root password; simply edit /etc/sudoers.
- It's easy to frequently change root's password because nobody
needs to know it.
- Because systems administrators must use their own personal
account to perform root tasks, it's easier to account for who
did what.
Resources
The sudo Web site -- http://www.gratisoft.us/sudo/sudo.html
Higgins, Bobby. "Creating User Accounts with Mkusers", UnixReview.com's
Shell Corner, November, 2001 -- http://www.unixreview.com/documents/s=1344/urm0111f/
The Expect home page -- http://expect.nist.gov/
John Spurgeon is a software developer and systems administrator
for Intel's Factory Integrated Information Systems, FIIS, in Aloha,
Oregon. He is currently training for the Furnace Creek 508 and still
enjoys turfgrass management, triathlons, and spending time with
his family.
Ed Schaefer is a frequent contributor to Sys Admin.
He is a software developer and DBA for Intel's Factory Integrated
Information Systems, FIIS, in Aloha, Oregon. Ed also edits the monthly
Shell Corner column on UnixReview.com. He can be reached at: shellcorner@comcast.net. |