- RHEL5 wants /etc/shadow to be 0400; RHEL6 wants this and /etc/gshadow at 0000. Not sure of the advantage of the latter.
-> This matters for SELinux. - RHEL5 wants module loading (DCCP, SCTP, Bluetooth, etc.) disabled with /bin/true; RHEL6 wants /bin/false. -> Not sure about this one. Perhaps it's for some logic checking code or it prevents overrides later down the stack. - 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). -> This was a change in auditd itself. "exit,always" is no longer valid. Trevor On Tue, Feb 26, 2013 at 10:05 AM, Shaw, Ray V CTR (US) < [email protected]> wrote: > 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 > > > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
