Some notes on current guide after review

Shawn Wells shawn at redhat.com
Tue Oct 23 00:46:22 UTC 2012


On 10/22/12 7:10 PM, Steve Grubb wrote:
> On Sunday, October 21, 2012 05:40:50 PM Jeffrey Blank wrote:
>>> 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).
> This is not what I would call a misconfiguration. Its an app that cannot take
> advantage of the built-in security features. If the program is not running as
> root, then its probably not so as serious.
>
> But a root running app would be a threat to the system if any vulnerability
> came along.

If checking for initrc_t isn't out of scope, I fail to see how checking 
for inetd_t would be.


>>> 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 ?
> Well, section 2.4 concerns itself with the password file (among other things).
> I was thinking about the checks that pwck does. And indeed running pwck -r on
> a rhel system does produce findings about the home dirs not existing. I don't
> know what most apps do, exist or stay wherever they are. But its not what was
> clearly intended by the packager.
This seems sane to be added as a rule.

>> (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.)
> <snipped a bunch>
>
>
>>> 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
> Yes, its been fixed for a while now.
>
>   
>>> 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.
> OK, just asking because this is the limitation in the sshd security policy for
> fips for anyone wanting this. :-)   But I personally have never used it so I
> don't know how often it is used in the real world. If anyone uses this, please
> speak up or it won't get checked.
Since we call out the need to use FIPS 140-2 algorithms, it's sane to 
add this.


More information about the scap-security-guide mailing list