Classification: UNCLASSIFIED Caveats: NONE > The ticketing system shows me you'd opened up a bunch of tickets to add > a "New rule" for items which were in the old RHEL 5 USGCB profile. > Okay, great, this helps with ensuring there is continuation of that > profile/baseline with some consistency.
I haven't opened any of these myself, but I did have a question along a similar line. Some things clash between the RHEL5 and RHEL6 STIG, which I'm discovering after having made my RHEL6 systems mostly-RHEL5-STIG-compliant and now starting on the RHEL6 STIG in earnest (I was just picking off items before). Specifically: - RHEL5 wants /etc/shadow to be 0400; RHEL6 wants this and /etc/gshadow at 0000. Not sure of the advantage of the latter. - RHEL5 wants module loading (DCCP, SCTP, Bluetooth, etc.) disabled with /bin/true; RHEL6 wants /bin/false. - RHEL5 wants audit rules to start with "exit,always"; RHEL6 wants them to start with "always,exit". Note that some of the actual RHEL6 benchmark content checks for both (e.g. adjtimex), while some (the majority) does not (e.g. chmod). I'm not sure what the level of interest is in making these agree. It would certainly help folks like me at the moment, who are uncertain which STIG might be used to evaluate RHEL6 systems while the RHEL6 STIG is still in draft status*. It would actually continue to help me down the road, due to simplified Puppet content (e.g. if I can have one /etc/modprobe.d/stig.conf file for both RHEL5 and RHEL6, yay). I haven't submitted anything to DISA regarding these; I focused there on items where I'd like to see the actual intent of the STIG change, and these are mostly just syntax. If there is consensus that the RHEL6 STIG should match the RHEL5 STIG, I'd be happy to try to do the work on (at least some of) these, because I've been wanting to start contributing and well, that seems like an easy start. In particular, since some of the audit checks already accept both sets of syntax, I would love to be able to make the rest do so as well (though I'm not sure how important it is for the prose to reflect this; currently, it doesn't). -- Ray Shaw Contractor, STG Unix support, Army Research Labs * While the 2nd and 3rd points are just syntax, and could be explained to an inspection team as the system actually being compliant, it makes SCAP scan results look bad for one or the other, and I suspect will result in (at least here) a small pile of extra documentation. It is also possible that an inspector could mark such an item as a failure. Classification: UNCLASSIFIED Caveats: NONE
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
