- 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) <ray.v.shaw.ctr@mail.mil> 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
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com

-- This account not approved for unencrypted proprietary information --