XS Blueprints:OTP root passwords

When deploying a large number of XS systems, root password management becomes an issue. While in many cases adminstration will be performed via automated scripts delivered through the network or other media, the need of ad-hoc maintenance in the field by technicians / sysadmins when things go wrong remains.

In other words, in the "things have gone wrong" - hardware issues, network issues or admin scripts that have broken the system, having the root password is important.

At the same time, having a common root password across a large number of XSs is a significant security risk. Even having a single unchanged root password for a single system is a security risk. This plan uses One Time Password lists - one for each XS - to manage these risks.

Scenarios

• The NOC team in the country of Rodrigombia - which has deployed 4 000 XSs to go with 60 000 XOs - needs to send a technician to resolve a problem with an XS in the village of Zernambuco. They want to give him root access that is valid only for this specific server, and for the time of this job, and the XS is not connected to the Internet or WAN. They trust the technician -- with root access, he can install a backdoor or create additional wheel accounts -- but do not want to risk the password to be stolen, lost or reused later.
• The Rodrigombia Technician is at the Zernambuco school. He needs to use the root password possibly several times as the fix may require reboots or login/logout cycles. A single-use OTP will not help.
• The NOC team of Sorialand is installing the software on 500 XSs and needs to collect the new OTPs as they are created in a safe way. So that misplacing the media (USB keys for example) does not risk the OTPs.
• In Gramponia the XS OS gets installed by a technician once he is at the school. So the technician needs a safe means to have a copy of the OTP for the NOC, and one for himself, as he will be doing post-install configuration of the network.
• The NOC team of Rodrigombia lost the OTP of a specific server and needs to recover it somehow.

Implementation Plan

The PAM SOTP library meets our requirements for the core usage:

• We can easily produce an OTP per server
• Each password can be valid for a period of time

There are some challenges still

• The password creation step needs quite a bit of entropy for true randomness, which we don't have on a server that is undergoing installation. We can provide at install time pre-created entropy files from an external source.
• The created OTP pad needs to be handled safely. This we can handle GPG-encrypting it with a pre-provided NOC public key.

So the plan is to

1. Package PAM SOTP for F7/F9
2. Scripts that during install or first boot
   1. Read the NOC pubkey off a USB key
   2. Read the installing technician pubkey off a USB key
   3. Create the OTP pad using entropy files from a USB key or optionally /dev/urandom (for test installs)
   4. Store 2 copies OTP on the USB key, encrypted with the technician pubkey and the NOC pubkey
   5. (perhaps) Store a copy of the NOC-pubkey-encrypted OTP pad in /var/www so it can be recovered
3. Get anaconda to skip asking for a root password

Note We also need to get PAM SOTP through a security review.

Alternative solutions

I spent a bit of time reading the doco on OPIE, but it is mainly about keeping a single password secure from eavesdroppers. See

• OPIE on F7 notes http://administratosphere.wordpress.com/2007/12/13/using-opie-on-fedora-7/ http://administratosphere.wordpress.com/2007/12/12/using-opie/
• Sample OPIE workflow... http://michele.pupazzo.org/diary/?p=203
• Some OPIE notes in spanish http://mitago.net/archives/2006/01/23/T03_51_24/