B.2.2. TMS Common Criteria Setup Procedures

These are the instructions for establishing a Common Criteria test environment for a TMS (Token Management System). Throughout this document, reference links to the Red Hat Certificate System guidance documents have been provided for users as either a well-documented stand-alone procedure, or as an optional source of additional information, and well be clearly denoted as to their purpose.


For the purposes of this test, Red Hat Directory Server 8.2 and Red Hat Certificate System subsystems are installed/configured on three different machines:
  • Machine-1: Directory Server, Certificate Authority subsystem
  • Machine-2: Data Recovery Management subsystem, Online Certificate Status Protocol Responder, Token Key Service subsystem
  • Machine-3: Token Processing System subsystem

B.2.2.1. Prerequisites: RHEL 5.6 Operating System Installation and Configuration

B. TMS Inventory
This test requires three 64-bit x86_64 machines each containing a 64-bit version of the Red Hat Enterprise Linux server 5.6 operating system for the x86_64 architecture. The 3 machines, which for the purposes of this document will be referred to with hostnames of server1.example.com, server2.example.com, server3.example.com should be registered with Red Hat Network (RHN) so that each machine may be fully updated with the latest packages for this version of the operating system. For example, once the operating system has been installed, this can be accomplished by becoming the root user, and executing the following command:
[root@server1]# yum -y update


The command should be executed on all three machines.
In the command, [root@server1]# is merely an example command-line prompt for Machine-1. This convention is used throughout this document. A similar convention is used when referring to Machine-2 and Machine-3.
Additionally, the user will need to have an nCipher nShield hardware security module (HSM) attached to this machine for compliance with FIPS 140-2 (Level 3). Details for installation and configuration of this device are provided in Section B., “Hardware Security Module Installation”.
Finally, for the purposes of Common Criteria certification of a TMS, the user will need to have the appropriate Red Hat subscriptions to download and install the following applications to all the three machines (server1.example.com,server2.example.com,server3.example.com) -- [detailed download, installation, and configuration instructions are provided below in various sections of this document]:
  • Apache 2.2.3
  • Tomcat 5.5.23
  • Red Hat Directory Server 8.2
  • Red Hat Certificate System subsystems:
    • Certificate Authority (CA)
    • Data Recovery Management (DRM) - also called a Key Recovery Authority (KRA)
    • Token Key Service (TKS)
    • Token Processing System (TPS)
    • Enterprise Security Client (ESC)
    • Online Certificate Status Protocol (OCSP) Responder
  • Red Hat Certificate System Console
  • Firefox 3.x
  • ESC (Enterprise Security Client)
  • Open JDK/JRE 1.6
  • JSS 4.6
  • NSS 3.12
  • nss-tools 3.12
  • mozldap-tools
B. Hardware Security Module Installation


HSM installation should be performed on Machine-1, Machine-2, and Machine-3.
If the nCipher nShield is not setup, insert the accompanying DVD, or mount the ISO and cd into the "Documents" folder. For example, assuming that the ISO is available in /tmp:
[root@server1]# mkdir /mnt/iso
[root@server1]# cd /mnt/iso/document
[root@server1]# mount -o loop /tmp/nCSS_linux64_user_11_40.iso /mnt/iso/
[root@server1]# ls
dr-xr-xr-x 2 root root    2048 Aug  2  2010 netHSM
-r-xr-xr-x 1 root root  967656 Aug  2  2010 nShield_Connect_Physical_Security_Checklist.pdf
-r-xr-xr-x 1 root root  310693 Aug  2  2010 nShield_Connect_Quick_Start_Guide.pdf
-r-xr-xr-x 1 root root 2409806 Aug  2  2010 nShield_Connect_User_Guide.pdf
-r-xr-xr-x 1 root root  610234 Aug  2  2010 nShield_Hardware_Installation.pdf
-r-xr-xr-x 1 root root  278386 Aug  2  2010 nShield_Quick_Start_Guide.pdf
-r-xr-xr-x 1 root root 2449190 Aug  2  2010 nShield_User_Guide.pdf
-r-xr-xr-x 1 root root  255087 Aug  2  2010 nToken_Install_Guide.pdf
Follow the vendor's instructions to setup the nCipher nShield.
Once the nCipher nShield has been installed, run the command below to ensure that the connection status is OK (by using grep'):
[root@server1]# /opt/nfast/bin/enquiry | grep -i status
 connection status    OK
To enable FIPS mode, open the security UI:
In the Security World tab, make sure that "Strict FIPS 140-2 Level III" is set to yes.
For more information on configuring FIPS mode, see the hardware vendor documentation.
B. SELinux Enforcement


SELinux Enforcement should be performed on Machine-1, Machine-2, and Machine-3.
SELinux is a collection of mandatory access control rules which are enforced across a system to restrict unauthorized access and tampering.
Red Hat recommends running Certificate System with SELinux in enforcing mode, to make the most of the security policies.
The /usr/sbin/getenforce command will give the status of SELinux. If running /usr/sbin/getenforce returns a result of either Disabled or Permissive, then it needs to be enabled to Enforcing. This may be accomplished by becoming the root user, editing the file '/etc/sysconfig/selinux' and configuring SELINUX=Enforcing, and re-booting the system.
[root@server1]# /usr/sbin/getenforce 
[root@server1]# /usr/sbin/sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted
B. Operating System User and Group Creation


Procedures in this section should be performed on Machine-1, Machine-2, and Machine-3.
This test requires that certain operating system users and groups exist. Login to the RHEL 5.6 machine as super user and ensure that both the UID and the gid of pkiuser are 17 by running by the following commands:
[root@server1]# grep pkiuser /etc/group
[root@server1]# grep pkiuser /etc/passwd
pkiuser:x:17:17:Red Hat Certificate System:/usr/share/pki:/sbin/nologin
If the pkiuser group is not present, make certain that the appropriate tool packages are installed and recheck the pkiuser user and group:
[root@server1]# rpm -q setup
[root@server1]# rpm -q shadow-utils
If the pkiuser user or group are still not present:
[root@server1]# /usr/sbin/groupadd -g 17 -r pkiuser
[root@server1]# /usr/sbin/useradd -g pkiuser -d /usr/share/pki -s /sbin/nologin -c "Red Hat Certificate System" -u 17 -r pkiuser
If the pkiuser user or group exist but do not have a uid:gid of 17:17:
[root@server1]# /usr/sbin/userdel pkiuser
[root@server1]# /usr/sbin/groupdel pkiuser
[root@server1]# /usr/sbin/groupadd -g 17 -r pkiuser
[root@server1]# /usr/sbin/useradd -g pkiuser -d /usr/share/pki -s /sbin/nologin -c "Red Hat Certificate System" -u 17 -r pkiuser
Create an administration group:
[root@server1]# /usr/sbin/groupadd -r pkiadmin
Create an auditor group:
[root@server1]# /usr/sbin/groupadd -r pkiaudit


Linux distinguishes system users such as pkiuser (which are often referred to as daemons which have no real person associated with them) from standard users that comprise the PKI administrators, agents, and auditors which are associated with real people.
Optional Reference: Users and Groups
If they do not already exist, create standard user accounts for either pkiadmin or pkiaudit, but never allow any standard user access to both groups.
For example, to create an administrator called John Smith:
[root@server1]# /usr/sbin/useradd -g pkiadmin -d /home/jsmith -s /bin/bash -c
"Red Hat Certificate System Administrator" -m jsmith
For example, to create an auditor called Sally Jones:
[root@server1]# /usr/sbin/useradd -g pkiaudit -d /home/sjones -s /bin/bash -c
"Red Hat Certificate System Auditor" -m sjones
B. Operating System User and Group Association


Procedures in this section should be performed on Machine-1, Machine-2, and Machine-3.
Once all operating system groups have been established (see Section B., “Operating System User and Group Creation”), the pkiuser system user must be associated with both the pkiadmin and the pkiaudit groups:
[root@server1]# /usr/sbin/usermod -a -G pkiadmin pkiuser
[root@server1]# /usr/sbin/usermod -a -G pkiaudit pkiuser


The pkiuser user is allowed to be associated with both the pkiadmin and the pkiaudit groups because pkiuser is a "system" user. Regular users are never allowed to be associated with both groups because no regular user is ever allowed to be both an administrator and an auditor.
If a pre-existing user is re-assigned to become an administrator, they can be associated with the pkiadmin group:
[root@server1]# grep mnelson /etc/group
[root@server1]# grep mnelson /etc/passwd
mnelson:x:1099:1099:Mary Nelson:/home/mnelson:/bin/bash
[root@server1]# /usr/sbin/usermod -a -G pkiadmin mnelson
Similarly, if a pre-existing user is re-assigned to become an auditor, they can be associated with the pkiaudit group:
[root@server1]# grep blarson /etc/group
[root@server1]# grep blarson /etc/passwd
blarson:x:1257:1257:Bob Larson:/home/blarson:/bin/bash
[root@server1]# /usr/sbin/usermod -a -G pkiaudit blarson
Additionally, since this test utilizes an nCipher nShield HSM, both the pkiuser user and any individuals in charge of administration of this device must be associated with the nfast group:
[root@server1]# /usr/sbin/usermod -a -G nfast pkiuser
[root@server1]# /usr/sbin/usermod -a -G nfast jsmith
[root@server1]# /usr/sbin/usermod -a -G nfast mnelson
Once all associations have been generated, ensure that the groups for users pkiuser, jsmith, sjones, mnelson, and blarson are correct:
[root@server1]# groups pkiuser jsmith sjones mnelson blarson
pkiuser : pkiuser pkiadmin pkiaudit nfast
jsmith : pkiadmin nfast
sjones : pkiaudit
mnelson : mnelson pkiadmin nfast
blarson : blarson pkiaudit