Cover V14, i02
feb2005.tar

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.