FIPS Operational Environment

Maintaining Software Integrity

Describe the checksum (.chk) files.

Configuring Discretionary Access Control

On Unix (including Linux and Mac OS X), discretionary access control can be configured by setting the file mode bits of the files.

Below we describe how to set the file mode bits to specify the set of roles that can access each component of the NSS cryptographic module.

Access to Stored Cryptographic Software and Cryptographic Programs

When installing the NSS cryptographic module library files, the operator shall use the chmod utility to set the file mode bits of the library files to 0755 so that all users can execute the library files, but only the files' owner can modify (i.e., write, replace, and delete) the files. For example,

 $ chmod 0755 libsoftokn3.so libfreebl*3.so

The file mode bits can be verified with the ls utility. For example,

 $ ls -l libsoftokn3.so libfreebl*3.so
 -rwxr-xr-x  1 wtchang wtchang  455411 Jun  8 17:07 libfreebl3.so
 -rwxr-xr-x  1 wtchang wtchang 1052734 Jun  8 17:07 libsoftokn3.so

On HP-UX PA-RISC, replace the .so suffix by .sl in the above commands. On Mac OS X, replace the .so suffix by .dylib in the above commands.

Access to Cryptographic Keys, CSPs, and Plaintext Data

Cryptographic keys, CSPs, and plaintext data are stored in the NSS databases. The NSS cryptographic module creates its database files with the 0600 permission bits so that only the owner can read or modify the database files. (See the dbsopen() or dbopen() calls in the nsslowcert_OpenPermCertDB, nsslowkey_OpenKeyDB, and secmod_OpenDB functions.) For example,

 $ ls -l *.db
 -rw-------  1 wtchang wtchang 65536 May 15 22:16 cert8.db
 -rw-------  1 wtchang wtchang 32768 May 15 22:16 key3.db
 -rw-------  1 wtchang wtchang 32768 May 15 22:15 secmod.db

Since the cryptographic keys and CSPs are stored in encrypted form, the owner needs to assume the NSS User role by authenticating with the password to decrypt the cryptographic keys and CSPs stored in the private key database.

Access to Audit Data

The NSS cryptographic module may use the Unix syslog() function and the audit mechanism provided by the operating system to audit events. Access to the audit data is described in the next two subsections.

Access to syslog Log Files

On Unix (including Linux and Mac OS X), the NSS cryptographic module uses the syslog() function to audit events, so the audit data are stored in the system log. Only the root user can modify the system log. On some platforms, only the root user can read the system log; on other platforms, all users can read the system log.

The system log is usually under the /var/adm or /var/log directory. The exact location of the system log is specified in the /etc/syslog.conf file. The NSS cryptographic module uses the default user facility and the info, warning, and err severity levels for its log messages. We give two examples below.

Red Hat Enterprise Linux 4: The /etc/syslog.conf file on Red Hat Enterprise Linux 4 has:

 *.info;mail.none;authpriv.none;cron.none                /var/log/messages

which specifies that /var/log/messages is the system log. The permission bits of the system log are:

 $ ls -l /var/log/messages
 -rw-------  1 root root 38054 Jun  9 10:18 /var/log/messages

so only the root user can read or modify the system log.

Solaris 10: The /etc/syslog.conf file on Solaris 10 has:

 *.err;kern.debug;daemon.notice;mail.crit        /var/adm/messages

which specifies that /var/adm/messages is the system log. The permission bits of the system log are:

 $ ls -l /var/adm/messages
 -rw-r--r--   1 root     root           0 Jun  7 03:10 /var/adm/messages

so all users can read the system log, but only the root user can modify it.

Access to System Audit Log

To meet the audit requirements of FIPS 140-2 at Security Level 2, on Red Hat Enterprise Linux 4 and Solaris, the NSS cryptographic module also uses the audit mechanism provided by the operating system to audit events, so the audit data are also stored in the system audit log. Only the root user can read or modify the system audit log.

On Red Hat Enterprise Linux 4, the system audit log is in the /var/log/audit directory. This directory and the log files in it have the following permission bits (the following commands were run as the root user; only the root user can run the second command):

 # ls -ld /var/log/audit
 drwxr-x---  2 root root 4096 Jun  1 19:50 /var/log/audit
 # ls -l /var/log/audit
 total 13460
 -rw-r-----  1 root root 3248038 Jun  8 17:50 audit.log
 -r--r-----  1 root root 5242886 Jun  1 19:50 audit.log.1
 -r--r-----  1 root root 5242936 May 20 18:01 audit.log.2

On Solaris default audit records are stored in system_name:/var/audit/.

Entry of Cryptographic Keys and CSPs

N/A. The NSS cryptographic module does not support manual entry of cryptographic keys and CSPs.