XS Blueprints:OTP root passwords: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
Line 7: Line 7:
= Scenarios =
= 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 do not want to risk the password to be stolen, lost or reused later.
* 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 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.

Revision as of 01:35, 23 July 2008

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.
  • 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

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


Walkthrough

TODOs and future work