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)
Tracking
(Not tracked)
RESOLVED
FIXED
3.11.2
People
(Reporter: glenbeasley, Assigned: wtc)
Details
(Whiteboard: FIPS)
Attachments
(5 files, 3 obsolete files)
4.59 KB,
text/plain
|
Details | |
20.25 KB,
patch
|
glenbeasley
:
review+
rrelyea
:
superreview-
|
Details | Diff | Splinter Review |
6.37 KB,
patch
|
Details | Diff | Splinter Review | |
5.54 KB,
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
2.36 KB,
patch
|
glenbeasley
:
review+
|
Details | Diff | Splinter Review |
Implement logging of auditable events VE06.17.01 (needed for level 2)
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 3.11
Assignee | ||
Comment 1•19 years ago
|
||
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
Comment 2•19 years ago
|
||
Per our meeting today, retargetting to 3.11.1 .
OS: Solaris → All
Hardware: Sun → All
Target Milestone: 3.11 → 3.11.1
Assignee | ||
Comment 3•19 years ago
|
||
Assignee | ||
Comment 4•19 years ago
|
||
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
Assignee | ||
Updated•19 years ago
|
Target Milestone: 3.11.1 → 3.11.2
Updated•19 years ago
|
Whiteboard: FIPS
Updated•19 years ago
|
QA Contact: jason.m.reid → libraries
Assignee | ||
Comment 5•19 years ago
|
||
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)
Assignee | ||
Comment 6•19 years ago
|
||
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.
Assignee | ||
Comment 7•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Attachment #220728 -
Flags: review?(glen.beasley) → review+
Assignee | ||
Comment 8•19 years ago
|
||
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 9•19 years ago
|
||
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-
Assignee | ||
Comment 10•19 years ago
|
||
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)
Assignee | ||
Comment 11•19 years ago
|
||
(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?
Comment 12•19 years ago
|
||
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 13•19 years ago
|
||
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+
Assignee | ||
Comment 14•19 years ago
|
||
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.)
Assignee | ||
Comment 15•19 years ago
|
||
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
Reporter | ||
Comment 16•19 years ago
|
||
Attachment #221869 -
Flags: review?(wtchang)
Assignee | ||
Comment 17•19 years ago
|
||
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-
Assignee | ||
Comment 18•19 years ago
|
||
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.
Reporter | ||
Comment 19•19 years ago
|
||
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)
Reporter | ||
Comment 20•19 years ago
|
||
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
Assignee | ||
Comment 21•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•18 years ago
|
Attachment #222130 -
Flags: review?(glen.beasley) → review+
You need to log in
before you can comment on or make changes to this bug.
Description
•