The root credential is the most powerful credential on a Linux/UNIX computer. If this credential is compromised, it is generally considered a full system compromise. While the default SAKA security—using Key Custodians to set their PINs to activate the hardware module each time the system starts up—is a reasonably secure procedure, it is generally recommended to have user applications run WITHOUT root privileges—if the application has bugs or is exploited, it will not give up privileged access.

SAKA practices this defense strategy by not requiring or using root privileges for normal operations—some parts of the installation process require root privileges, but once completed, the web service application that provides cryptographic services does not need root access. Because any human (or attacker) that has access to the root account can assume the identity of any other Linux account, it would be possible for an attacker who has compromised the root account to assume the SAKA web service application ID and gain access to the PINs that guard the keys in the cryptographic hardware module from main memory with the appropriate tools.

As a consequence, sites may want to ensure that the root account is restricted through policy, procedural and technical controls. While this document does not go into the policy and procedural aspects of controlling root access, the following technical controls can help mitigate some of the risks of the root account becoming compromised. Site administrators are encouraged to review other resources to determine the optimum mechanism for protecting and/or controlling root privileges on their systems, so they gain a broader perspective on these controls.

1. Setup an unlock account on the Linux system. This account becomes the fail-safe measure to recover access to the root account in the event it is needed for extraordinary administrative actions.

2. Add the unlock account to /etc/sudoers with the ability to unlock the root account. Replace the <FQDN> with the fully-qualified domain name of the SAKA server.

   shell>unlock <FQDN>=/usr/sbin/usermod --unlock root

3. Add the normal Linux account of the Systems Administrator (SA) to /etc/sudoers to perform specific SA tasks (as defined by company policy). This ensures that SAs can perform their day-to-day jobs—backup, restore, log management, performance management, patching, etc. These accounts must be the only legitimate means of managing the SAKA system.

   For tighter control, depending on company policy, sites may add multi-factor authentication tokens to the system to ensure only legitimate SAs with 2-factor tokens can login into SA accounts in SAKA.

4. Add a watch on /etc/sudoers and on /usr/bin/sudo to audit modifications to the former and use of the latter:

   auditctl -w /etc/sudoers -pwar -k sudoers
   auditctl -w /usr/bin/sudo -px -k sudo-exec

   This first watch monitors for writes, appends, and reads of the /etc/sudoers file, then logs them. Logged records can be searched with filter key sudoers. The second watches for execution of the sudo command and log any matches with a filter key of sudo-exec.

   auditd should be turned on to monitor for access to the sudo command and report it to appropriate authorities for review (third-party reporting tools may also be used for this purpose, if desired).

5. Finally, lock the root account on the system:

   shell>>/usr/sbin/usermod --lock root

   This has the effect of disabling the root account so no one can gain access to the account.