Closed Bug 298506 Opened 19 years ago Closed 19 years ago

Implement logging for auditable events required by FIPS 140-2

Categories

(NSS :: Libraries, enhancement, P1)

3.10
enhancement

Tracking

(Not tracked)

RESOLVED FIXED
3.11.2

People

(Reporter: glenbeasley, Assigned: wtc)

Details

(Whiteboard: FIPS)

Attachments

(5 files, 3 obsolete files)

Implement logging of auditable events VE06.17.01 (needed for level 2)
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 3.11
I looked into this today and found that this is much more work than I thought because we must use an audit mechanism provided by the OS and can't create our own audit log. Here is the exact wording of the relevant AS from Derived Test Requirements for FIPS PUB 140-2: AS06.17: (Levels 2, 3, and 4) The operating system shall provide an audit mechanism to record modifications, accesses, deletions, and additions of cryptographic data and CSPs. Note: An assumption of this assertion is that the cryptographic module must use the audit mechanism provided by the operating system to audit the identified events. It is not sufficient for the cryptographic module software to use another file as its audito log, no matter how well protected. [Wan-Teh's Note: "CSPs" stands for "critical security parameters", e.g., secret or private keys, passwords, and PINs.] Another consequence is that the audit mechanism will be different between Solaris and Red Hat Enterprise Linux (RHEL), the two platforms we want to do Level 2 validation on. So Glen, please ask Sun's Solaris team about the audit mechanism in Solaris or Trusted Solaris that you can use. I will do the research on the audit mechanism in RHEL. I suggest that we not implement this feature on any other platform (in particular Windows 2000, which could be a Level 2 platform, see http://www.microsoft.com/technet/security/prodtech/Windows2000/w2kccwp.mspx) in NSS 3.11 to save time.
Severity: normal → enhancement
Per our meeting today, retargetting to 3.11.1 .
OS: Solaris → All
Hardware: Sun → All
Target Milestone: 3.11 → 3.11.1
I only implemented logging of the PKCS #11 Security Officer (SO) functions and "use of an authentication mechanism (e.g., login) associated with the cryptographic module": C_InitToken C_InitPIN C_SetPIN C_Login
Target Milestone: 3.11.1 → 3.11.2
Whiteboard: FIPS
QA Contact: jason.m.reid → libraries
Attached patch Proposed patchSplinter Review
The auditing capability can only be enabled when the softoken is in FIPS mode. To enable the auditing capability, set the environment variable NSS_ENABLE_AUDIT to 1 before you start an NSS-based application. Many auditable events required by FIPS 140-2 do not apply to NSS. We record the following auditable events. - self-test failure. This has the following cases * power-up cryptographic algorithm test failed (in C_Initialize) * on-demand cryptographic algorithm test failed (in C_Login) * power-up software/firmware integrity test failed (in C_Initialize) * continuous random number generator test failed (in C_GenerateRandom) * pair-wise consistency test failed (in C_GenerateKeyPair) - module initialization (in C_InitToken) - password initialization (in C_InitPIN) - FIPS mode enabled - FIPS mode disabled - password change (in C_SetPIN) - login attempt (in C_Login) - logout (in C_Logout) This patch only implements an implementation for Unix using the syslog() function. In the future we can add an implementation for Windows using Windows NT event logging. Here are some comments on the implementation. The new global variable sftk_audit_enabled indicates whether the auditing capability is enabled or disabled. It is initialized to PR_FALSE (auditing disabled). In FC_Initialize, we set sftk_audit_enabled to PR_TRUE if the value of the NSS_ENABLE_AUDIT environment variable is 1. We check sftk_audit_enabled before constructing and logging an audit message. There are three severity levels of audit messages: error, warning, and informational. Most audit mechanisms, including syslog(), allow you to specify messages of what severity levels are actually written to the audit log. The new function sftk_LogAuditMessage logs the specified audit message. We prepend the crypto module's name, process ID, and user ID to the audit message. I try to use the localized crypto module name (slot->tokDescription). However, if we need to audit before 'slot' is created, I use the default FIPS token name. This is why I have to declare sftk_getDefTokName in pkcs11i.h so that I can call that function from fipstokn.c. I also have to make sftk_SlotFromID fail gracefully if the slot hashtable hasn't been created. Some FC_XXX function calls are always logged. In those functions, I need to get rid of all the early returns, so that I can do audit logging before the return statement. This is why some of the FC_XXX functions have more changes than just audit logging. I did some code cleanup such as changing FIPS 140-1 to FIPS 140-2 and Netscape to NSS and fixing incorrect file names PKCS11.c and SFTKFIPS.c.
Attachment #204093 - Attachment is obsolete: true
Attachment #220728 - Flags: superreview?(rrelyea)
Attachment #220728 - Flags: review?(glen.beasley)
This patch illustrates how we might implement auditing for Windows using Windows NT event logging. This patch is incomplete. I attached it here so that we know which Windows functions we can use.
Comment on attachment 220731 [details] [diff] [review] For reference only: incomplete patch illustrating use of Windows NT event logging I forgot to mention that a complete implementation for Windows requires the use of the message compiler (mc.exe) and message resources, which this patch doesn't show.
Attachment #220728 - Flags: review?(glen.beasley) → review+
Comment on attachment 220728 [details] [diff] [review] Proposed patch With Glen's review, I checked in this patch on the NSS trunk (3.12) and the NSS_3_11_BRANCH (3.11.2). I'd still like Bob to review this patch because softoken is his area. If Bob suggests any changes, I will make them in another patch.
Comment on attachment 220728 [details] [diff] [review] Proposed patch While in the normal course of events there is usually only one FIPS token, it is possible for applications to initalize others. If you have to log the token name, then the logging code should accept a SLOT_ID. Slots id's should be looked up from the session id for those functions that take session id (sftk_SlotFromSessionHandle will do this). places like C_Initialize could use the base FIPS token. Other than that the patch is fine.
Attachment #220728 - Flags: superreview?(rrelyea) → superreview-
Bob, thanks for the code review. I don't have to log the token name. I just wanted to indicate that these messages come from the NSS component of an application. I wanted to avoid the internationalization issue, so I looked for 1. a string that doesn't need to be internationalized: for example, "NSS". I didn't use "NSS" because on Unix/Linux "NSS" also means "Name Service Switch". 2. a string that's already localized: this is why I used the token name because I know NSS-based apps call PK11_ConfigurePKCS11 to localize the token name. It's not easy to test the auditing code because I had to manually modify the NSS code to inject various errors. So in the interest of time, I decided to go back to option 1, and use "NSS libsoftokn3.so" in the audit messages. I also backed out the two changes that were required by the logging of the token name. The second change of this patch is to use the Linux audit mechanism, in addition to syslog(), when running on Linux. Unfortunately I have to load the Linux audit library and look up the audit function symbols at run time because neither the audit subsystem (the audit and audit-libs packages) nor the audit subsystem SDK (the audit-libs-devel package) is installed in every Linux system.
Attachment #221521 - Flags: review?(rrelyea)
(In reply to comment #9) Bob wrote: > (From update of attachment 220728 [details] [diff] [review] [edit]) > While in the normal course of events there is usually only one FIPS token, it > is possible for applications to initalize others. I didn't know about this. lib/softoken has some code that assumes there is only one FIPS token/slot. If you search for FIPS_SLOT_ID in lib/softoken, you will see some tests that compare slotID with FIPS_SLOT_ID. Do we have to review and fix those tests? Is "sftk_GetModuleIndex(slotID) == NSC_FIPS_MODULE" the correct test?
Yes, two of those tests are wrong (it looks like there are problems in C_GetMechanism* (List,Info) as well. The better thing to do is create an 'stfk_isFIPS' function and do the appropriate test in that (the current best test is the one you described..). bob
Comment on attachment 221521 [details] [diff] [review] Do not log token name. Use Linux audit mechanism. r+ with the following caveat: verify that your removal of the santity check for nscSlotHashTable (added in your previous patch) was intentional.
Attachment #221521 - Flags: review?(rrelyea) → review+
Comment on attachment 221521 [details] [diff] [review] Do not log token name. Use Linux audit mechanism. I checked in the patch "Do not log token name. Use Linux mechanism." on the NSS trunk (3.12) and the NSS_3_11_BRANCH (3.11.2). I confirm that the removal of the santity check for nscSlotHashTable was intentional. That check was added to allow sftk_SlotFromID to be called from C_Initialize without crashing. With this patch, the audit logging code doesn't call sftk_SlotFromID at all. So that check isn't necessary any more. (I probably shouldn't have called sftk_SlotFromID from C_Initialize anyway.)
Glen, I found the following three blog entries of Martin Englund's to be a great tutorial on the Solaris auditing framework API: http://blogs.sun.com/roller/page/martin/20050910 http://blogs.sun.com/roller/page/martin/20050913 http://blogs.sun.com/roller/page/martin/20050920
Attached patch Solaris Audit logging (obsolete) — Splinter Review
Attachment #221869 - Flags: review?(wtchang)
Comment on attachment 221869 [details] [diff] [review] Solaris Audit logging Do you need to add -lbsm to OS_LIBS in cmd/platlibs.mk? >+ //write the audit tokens to the audit record: >+ if (au_write(rd, au_to_text(message)) || >+ au_write(rd, au_to_return32(0, 0)) ) { /* return token */ >+ PR_smprintf_free(message); >+ return; >+ } We also need to close rd with this call: au_close(rd, AU_TO_NO_WRITE, AUE_FIPS_AUDIT); Note the use of AU_TO_NO_WRITE. ^^ >+ //close the record and send it to the audit trail: >+ if (au_close(rd, AU_TO_WRITE, AUE_FIPS_AUDIT)) { >+ PR_smprintf_free(message); >+ return; >+ } >+ >+ PR_smprintf_free(message); You can just say: (void)au_close(rd, AU_TO_WRITE, AUE_FIPS_AUDIT); PR_smprintf_free(message);
Attachment #221869 - Flags: review?(wtchang) → review-
Comment on attachment 221869 [details] [diff] [review] Solaris Audit logging >+ int result = (severity != NSS_AUDIT_ERROR); /* 1=success; 0=failed */ ... >+ //write the audit tokens to the audit record: >+ if (au_write(rd, au_to_text(message)) || >+ au_write(rd, au_to_return32(0, 0)) ) { /* return token */ >+ PR_smprintf_free(message); >+ return; >+ } The second argument to au_to_return32 should depend on 'severity' or 'result'. It seems that 'success' is 0, but I don't know what 'failure' is. We don't have the error number so it's fine to always report 0. Alternatively, we can omit the au_to_return32 call.
Attached patch Audit logging for Solaris (obsolete) — Splinter Review
Wan-Teh, I added your changes. -lbsm to OS_LIBS in cmd/platlibs.mk is there for bltest and fipstest commands.
Attachment #221869 - Attachment is obsolete: true
Attachment #222074 - Flags: review?(wtchang)
Instead of changing platlibs.mk would you prefer that I add ifeq ($(OS_TARGET), SunOS) OS_LIBS += -lbsm endif to the Makefile's of bltest, fipstest, certcgi, ocspclnt, rsaperf, signtool, and signver. -glen
Glen, I made the following changes to your patch. 1. In cmd/platlibs.mk, I moved the new code ifeq ($(OS_TARGET), SunOS) OS_LIBS += -lbsm endif to the USE_STATIC_LIBS section because only the tools that are linked with NSS static libraries need to link with -lbsm. 2. I changed C++ comments // to C comments /* */. 3. Since we call au_to_close last, there is no point in checking its return value. I've checked in this patch on the NSS trunk (3.12) and NSS_3_11_BRANCH (3.11.2). Please still review it and suggest changes with a new patch. Checking in cmd/platlibs.mk; /cvsroot/mozilla/security/nss/cmd/platlibs.mk,v <-- platlibs.mk new revision: 1.46; previous revision: 1.45 done Checking in lib/softoken/config.mk; /cvsroot/mozilla/security/nss/lib/softoken/config.mk,v <-- config.mk new revision: 1.19; previous revision: 1.18 done Checking in lib/softoken/fipstokn.c; /cvsroot/mozilla/security/nss/lib/softoken/fipstokn.c,v <-- fipstokn.c new revision: 1.14; previous revision: 1.13 done Checking in cmd/platlibs.mk; /cvsroot/mozilla/security/nss/cmd/platlibs.mk,v <-- platlibs.mk new revision: 1.43.2.3; previous revision: 1.43.2.2 done Checking in lib/softoken/config.mk; /cvsroot/mozilla/security/nss/lib/softoken/config.mk,v <-- config.mk new revision: 1.18.2.1; previous revision: 1.18 done Checking in lib/softoken/fipstokn.c; /cvsroot/mozilla/security/nss/lib/softoken/fipstokn.c,v <-- fipstokn.c new revision: 1.11.2.3; previous revision: 1.11.2.2 done
Attachment #222074 - Attachment is obsolete: true
Attachment #222130 - Flags: review?(glen.beasley)
Attachment #222074 - Flags: review?(wtchang)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #222130 - Flags: review?(glen.beasley) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: