FIPS Operational Environment

Operational Environment

The operational environment for the NSS cryptographic module is a general purpose, modifiable operational environment that uses one of the following commercially-available operating systems:

• Security Level 1
  • Red Hat Enterprise Linux 4
  • Windows XP Service Pack 2
  • Solaris 10
  • HP-UX B.11.11
  • Mac OS X 10.4
• Security Level 2
  • Red Hat Enterprise Linux 4: CAPP EAL4+
  • Trusted Solaris 8: LSPP, CAPP, and RBACPP; EAL4

Single Operator Mode of Operation

All the major general purpose operating systems today are multi-user OS. When the NSS cryptographic module is used at Security Level 1, only one user account should be created in the OS. The following explains how to configure each OS for single user.

Mac OS X Instructions

To delete other user accounts

1. Log into your user account.
2. From the Apple menu, choose System Preferences.
3. From the View menu, choose Accounts.
4. All the user accounts are listed on the left hand side of the Accounts dialog. Your user account is listed under My Account and should have Admin privilege. If there is no user account under Other Accounts, stop here. Otherwise, follow the steps below to delete the other accounts.
5. If the lock icon at the lower left corner of the Accounts dialog is locked, click the lock to make changes.
6. Select a user account under Other Accounts.
7. Click the minus sign (-) at the lower left corner of the Accounts dialog to delete the selected user account.
8. Repeat the above two steps until there is no user account under Other Accounts.

To turn off remote login and other services

1. Log into your user account.
2. From the Apple menu, choose System Preferences.
3. From the View menu, choose Sharing.
4. In the Sharing dialog, select the Services tab. All the services are listed under the message "Select a service to change its settings." If none of the checkboxes is checked, stop here. Otherwise, follow the steps below.
5. If the lock icon at the lower left corner of the Sharing dialog is locked, click the lock to make changes.
6. Unckeck all the checkboxes, including Remote Login, FTP Access, and Apple Remote Desktop.

See also

• NSA, Apple Mac OS X v10.3.x "Panther" Security Configuration Guide. Read Chapter 4 Configuring System Settings, Section Managing System Preferences, Subsection Sharing, pages 37-39. Check the NIST Security Configuration Checklists Repository for newer versions of this document.

Unix Instructions

The general idea is the same across all Unix variants.

• Remove all login accounts except "root" (the superuser).
• Disable NIS and other name services for users and groups.
• Turn off all remote login, remote command execution, and file transfer daemons.

The specific procedures for each of the UNIX variants are described below.

HP-UX

1. Log in as the "root" user.
2. Edit the system file /etc/passwd and remove all the users except "root" and the pseudo-users. Make sure the password fields for the pseudo-users are a star (*). This prevents login as the pseudo-users.
3. Edit the system file /etc/nsswitch.conf. Make sure that files is the only option for passwd and group. This disables NIS and other name services for users and groups.
4. Edit the system file /etc/inetd.conf. Remove or comment out the lines for remote login, remote command execution, and file transfer daemons such as telnetd, rlogind, remshd, rexecd, ftpd, and tftpd.
5. Reboot the system for the changes to take effect.

Red Hat Enterprise Linux

1. Log in as the "root" user.
2. Edit the system files /etc/passwd and /etc/shadow and remove all the users except "root" and the pseudo-users. Make sure the password fields in /etc/shadow for the pseudo-users are either a star (*) or double exclamation mark (!!). This prevents login as the pseudo-users.
3. Edit the system file /etc/nsswitch.conf and make files the only option for passwd, shadow, and group. This disables NIS and other name services for users and groups.
4. In the /etc/xinetd.d directory, edit the files eklogin, gssftp, klogin, krb5-telnet, kshell, rexec, rlogin, rsh, rsync, telnet, and tftp, and set the value of disable to yes.
5. Reboot the system for the changes to take effect.

Solaris

1. Log in as the "root" user.
2. Edit the system files /etc/passwd and /etc/shadow and remove all the users except "root" and the pseudo-users. Make sure the password fields in /etc/shadow for the pseudo-users are either a star (*) or NP. This prevents login as the pseudo-users.
3. Edit the system file /etc/nsswitch.conf and make files the only option for passwd, shadow, and group. This disables NIS and other name services for users and groups.
4. In the /etc/inetd.d directory, edit the files eklogin, gssftp, klogin, krb5-telnet, kshell, rexec, rlogin, rsh, rsync, telnet, and tftp, and set the value of disable to yes.
5. Reboot the system for the changes to take effect.

Windows XP Instructions

1. Log on with your user account.
2. Click Start > Control Panel > User Accounts.
3. Make sure the Guest account is off. If the Guest account is on, click its icon and click "Turn off the guest account" to turn it off.
4. Follow the steps below to delete the other accounts.
   Note: User Accounts may show some accounts that are used by programs. For example, ASP.NET Machine Account (shown as ASP.NET Machine A... in User Accounts) is used by Microsoft .NET Framework 1.1 for running the ASN.NET worker process (aspnet_wp.exe), and SQLDebugger is used by Microsoft Visual Studio .NET Debugger. Deleting such accounts could cripple the programs using these accounts. As a precaution, remove those programs before deleting these accounts.
5. Click the icon of an account other than your own account and the Guest account.
6. Click "Delete the account".
7. Repeat the above two steps until all the accounts other than your own account and the Guest account have been deleted.

See also

• SP 800-68 Guidance for Securing Microsoft Windows XP Systems for IT Professionals: A NIST Security Configuration Checklist. Section 6.5 System Services explains how to disable unnecessary services such as NetMeeting Remote Desktop Sharing and Telnet to reduce the number of attack vectors against the system. Section 7.2.1 Built-in Accounts explains how to disable default user accounts, which are often used in exploits against computer systems. Note that the recommendation in Section 7.2.3 Daily Use Accounts is at odds with the single operator mode of operation requirement of FIPS 140-2 Security Level 1.
• Draft SP 800-69 Draft Special Publication 800-69, Guidance for Securing Microsoft Windows XP Home Edition: A NIST Security Configuration Checklist. Read Appendix B.2 Disable Default User Accounts and Appendix B.5 Disable Unneeded Services. Note that Appendix A Essential Security Settings, Step 6: Set Up Limited User Accounts is at odds with the single operator mode of operation requirement of FIPS 140-2 Security Level 1.

Software Integrity Test

The Digital Signature Algorithm (DSA) is used as the Approved authentication technique (validation certificate# 172) for the integrity test of the software components. Software components protected using the digital signatures are the softoken (PKCS #11) and freebl libraries (e.g., libsoftokn3.so and libfreebl3.so). (See Security Policy Rule #36 for a list of module files by platform.) When the softoken and freebl libraries are built, a DSA public/private key pair with a 1024-bit prime modulus p is generated, the private key is used to generate a DSA signature of the library, and the public key and signature are stored in a file with the name libraryname.chk. When the self-test is initiated (e.g., at initialization for the FIPS mode), the module verifies the signatures (in the libraryname.chk files) of the softoken and freebl libraries. If the signature verification fails, the self-test fails.

FC_Initialize calls nsc_CommonInitialize and then the DSA signature is verified before the library initialization is allowed to proceed.

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.

Auditable Events

Many auditable events required by FIPS 140-2 are related to the crypto officer role. In the NSS cryptographic module, the crypto officer role is only used to perform these functions:

• install the module,
• initialize or re-initialize the module, and
• initialize the NSS User's password.

Moreover, the operator assumes the crypto officer role implicitly when he performs a crypto officer function. No explicit request or authentication (beyond logging into the OS user account of the operator) is required.

Every audit record contains the following information about the event:

• date and time of the event
• the string "NSS <softoken library name>", which identifies the NSS cryptographic module. On Red Hat Enterprise Linux and Solaris, this string is "NSS libsoftokn3.so"
• process ID (pid) of the process using the NSS cryptographic module
• user ID (uid) of the user who owns the process
• the audit text message, which usually consists of
  • the PKCS #11 function that generated the event. For example, FC_Login.
  • the arguments and return code (error code) of the function. Arguments that contain sensitive information such as passwords are omitted.
  • (optional) an error message. For example, "power-up self-tests failed".

The following events are auditable by the NSS cryptographic module.

• attempts to provide invalid input for crypto officer functions: We log the use of all crypto officer functions with the return code. The return code tells us whether the operator attempted to provide invalid input.
  • FC_InitToken(slotID, pPin, ulPinLen, pLabel)
    • If slotID is invalid, the return code 0x00000003 (CKR_SLOT_ID_INVALID) is logged.
    • The other input arguments are ignored. (The password of the Crypto Officer is not used because the module depends on the OS to authenticate the Crypto Officer and doesn't perform further authentication.)
  • FC_InitPIN(hSession, pPin, ulPinLen)
    • If hSession is invalid, the return code 0x000000B3 (CKR_SESSION_HANDLE_INVALID) is logged.
    • If the password that pPin points to has an invalid UTF-8 character, the return code 0x000000A1 (CKR_PIN_INVALID) is logged.
    • If ulPinLen is too short or too long, or the password that pPin points to is too weak (doesn't have enough character types), the return code 0x000000A2 (CKR_PIN_LEN_RANGE) is logged.
• the addition or deletion of an operator to/from a crypto officer role: Since any authorized operator can assume the crypto officer role, this event is equivalent to the addition or deletion of a user account in the OS. These events are recorded by the audit mechanism of the OS.
  • Red Hat Enterprise Linux 4: FAU_SMR.1 Modifications to the group of users that are part of a role are auditable events. (See Security Target, Table 5-1, page 32.)
  • Trusted Solaris 8: Audit.5 The creation, deletion, disabling or enabling of user accounts is auditable. (See Security Target, page 55.)
• operations to process audit data stored in the audit trail: these operations are recorded by the audit mechanism of the OS.
  • Red Hat Enterprise Linux 4: FAU_SAR.1 Reading of information from the audit records and FAU_SAR.2 Unsuccessful attempts to read information from the audit records are auditable events. (See Security Target, Table 5-1, pages 29-30.)
  • Trusted Solaris 8: Audit.2 Attempts to access to objects are auditable. (See Security Target, page 54.)
• requests to use authentication data management mechanisms
  • FC_InitPIN calls (which initialize the NSS User's password)
    • "C_InitPIN(hSession=<session handle>)=<return code>"
  • FC_SetPIN calls (which change the NSS User's password)
    • "C_SetPIN(hSession=<session handle>)=<return code>"
• use of a security-relevant crypto officer function
  • FC_InitToken calls (which re-initialize the module)
    • "C_InitToken(slotID=<slot ID>, pLabel="<token label>")=<return code>"
  • FC_InitPIN calls (which initialize the NSS User's password)
    • "C_InitPIN(hSession=<session handle>)=<return code>"
• requests to access authentication data associated with the cryptographic module
  • N/A. The module doesn't give the operator access to the authentication data.
• use of an authentication mechanism (e.g., login) associated with the cryptographic module
  • FC_Login calls
    • "C_Login(hSession=<session handle>, userType=<user type>)=<return code>"
  • FC_Logout calls
    • "C_Logout(hSession=<session handle>)=<return code>"
• explicit requests to assume a crypto officer role
  • N/A. The crypto officer role is assumed implicitly when the operator performs crypto officer functions.
• the allocation of a function to a crypto officer role
  • N/A. The functions allocated to the crypto officer role are fixed.
• other auditable events
  • Power-up self-test failure
    • "C_Initialize()=<return code> power-up self-tests failed"
  • Pair-wise consistency test failure
    • "C_GenerateKeyPair(hSession=<session handle>, pMechanism->mechanism=<mechanism>)=<return code> self-test: pair-wise consistency test failed"
  • Continuous random number generator test failure
    • "C_GenerateRandom(hSession=<session handle>, pRandomData=<pointer>, ulRandomLen=<length>)=<return code> self-test: continuous RNG test failed"
  • Switching between FIPS and non-FIPS modes
    • "enabled FIPS mode"
    • "disabled FIPS mode"