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