Some notes on current guide after review
Jeffrey Blank
blank at eclipse.ncsc.mil
Sun Oct 21 21:40:50 UTC 2012
Thanks very much for your expert review, Steve.
Notes below.
> 2.3.6 - selinux unconfined check should also look for processes with inetd_t
> label - excluding xinetd itself. Am inetd_t label also indicates a daemon that
> has no policy for it.
This is a very good point for the SELinux guidance discussion, and has
been added to:
https://fedorahosted.org/scap-security-guide/ticket/98
For now it seems out of scope for the STIG profile (as it's not intended
to be an unconstrained hunt for potential misconfigurations).
> 2.4 - should a check exist to make sure the stated home dir exists?
I can't tell what you're after; in this a section from the guide format,
as shown at
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide.html
?
(Things are not settled down enough to reliably refer to sections by
number; name is preferred. Those doing programmatic manipulation are
advised to use the XCCDF Rule id as an anchor.)
> 2.4.2 - also need to look in /etc/libuser.conf for crypt_style and set it to
> SHA512.
Just did it, and committed it (also emailed to list). I also broke
apart an existing Rule to make it more granular.
Hmmm sure would be nice if there were one place to set what algorithm
should be used for hashing... :)
> 2.4.2.4.a - error, has pam_tally2 instead of pam_faillock.
Yeah, this was once correct (I think, even though it was a giant
complicated mess) and then was "fixed" to its current state. Perhaps
David or Michele can revisit for us.
> 2.4.4.2.a - vlock no longer meets common criteria requirements. It now
> requires automatic screen locking after a timeout and reauthentication to
> unlock. This was accomplished with the screen program and some code in various
> shell startups.
This ticket has been open forever. Perhaps Michele can help us.
> 2.5.8.2 - should it say RSA 2048 or higher and SHA2 hash? By 2014 this is
> mandatory. Also, probably beyond scope, keys needed for FIPS compliance should
> only be generated when the system is in FIPS mode to ensure the RNG passes its
> periodic test during key generation.
The entire section describing SSL is a nice HOWTO section (so at least
we're avoiding high-priority STIG work for now), so I just opened a
ticket to note that we should handle/update:
https://fedorahosted.org/scap-security-guide/ticket/117
> 2.6? - Do we care about setting kernel.dmesg_restrict = 1 in a sysctl?
Yes. I just opened a ticket. Not a blocker for the STIG (but would be
recommended if available in time):
https://fedorahosted.org/scap-security-guide/ticket/118
> 3.4.3.k - the approved ciphers in FIPS mode are: "aes128-ctr, aes192-ctr,
> aes256-ctr, aes128-cbc, 3des-cbc, aes192-cbc, aes256-cbc". A subset of these
> are listed and I don't know if there was a reason why all of them are not
> allowed.
I think there was a bug in the CBC mode once, and this influenced what
was in the RHEL 5 STIG, and that was carried into here. Since the bug
has long since been patched (and was never in RHEL 6), this should be
fixed. Perhaps Michele can help us:
https://fedorahosted.org/scap-security-guide/ticket/119
> 3.4.3.l Would you want to add FIPS approved MACs? If so they are: "hmac-sha1"
> and/or “hmac-sha1-96”. A SHA2 HMAC might be added in the future, but its
> undetermined yet.
I'm not feeling ambitious anymore. Maybe someone else is, or wants to
send us a patch.
More information about the scap-security-guide
mailing list