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.