Changes

Jump to: navigation, search

FIPS Operational Environment

114 bytes added, 23:09, 27 July 2006
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 <code>chmod</code> utility to set the file mode bits of the NSS library files to '''0755''' so that all users can execute the NSS 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 <code>ls</code> utility. For example,
===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 <code>dbsopen()</code> or <code>dbopen()</code> calls in the [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pcertdb.c.dep.html#nsslowcert_OpenPermCertDB <code>nsslowcert_OpenPermCertDB</code>], [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/keydb.c.dep.html#nsslowkey_OpenKeyDB <code>nsslowkey_OpenKeyDB</code>], and [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pk11db.c.dep.html#secmod_OpenDB <code>secmod_OpenDB</code>] functions.) For example,
$ ls -l *.db
-rw------- 1 wtchang wtchang 65536 May 15 22:16 cert8.db
===Access to Audit Data===
The NSS cryptographic module may use the Unix <code>syslog()</code> 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 <code>syslog()</code> function to audit events, so the NSS 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 <code>/var/adm</code> or <code>/var/log</code> directory. The exact location of the system log is specified in the <code>/etc/syslog.conf</code> 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 <code>/etc/syslog.conf</code> file on Red Hat Enterprise Linux 4 has:
====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 NSS 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 <code>/var/log/audit</code> 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):
===Entry of Cryptographic Keys and CSPs===
'''N/A'''. The NSS cryptographic module does not support manual entry of cryptographic keys and CSPs.
Canmove, confirm
937
edits

Navigation menu