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.
NOTE
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
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
NOTE
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.2.2.1.2, “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 10 and later
- ESC (Enterprise Security Client)
- Open JDK/JRE 1.6
- JSS 4.6
- NSS 3.12
- nss-tools 3.12
- mozldap-tools
NOTE
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
Optional Reference: Section 8.1, “Setting up HSMs for Storing Certificate System Subsystem Keys and Certificates”
To enable FIPS mode, open the security UI:
/opt/nfast/bin/ksafe
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.
NOTE
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.
Optional Reference: SELinux section of the Red Hat Enterprise Linux Deployment Guide
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 Enforcing
[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
Optional Reference: Section 5.3.6, “Enabling SELinux”
NOTE
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 pkiuser:x:17:
[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 setup-2.5.58-7.el5
[root@server1]# rpm -q shadow-utils shadow-utils-4.0.17-15.el5
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
Note
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
Optional Reference: Section 5.3.7, “Setting up Operating System Users and Groups”
NOTE
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.2.2.1.4, “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
Important
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 mnelson:x:1099:
[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 blarson:x:1257:
[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
Optional Reference: Section 5.3.7.2.3, “Associating Existing User Accounts with PKI Groups”