- RHEL5 wants /etc/shadow to be 0400; RHEL6 wants this and /etc/gshadow at<br>
0000.  Not sure of the advantage of the latter.<br><br>-&gt; This matters for SELinux.<br><br>
- RHEL5 wants module loading (DCCP, SCTP, Bluetooth, etc.) disabled with<br>
/bin/true; RHEL6 wants /bin/false.<br><br>-&gt; Not sure about this one. Perhaps it&#39;s for some logic checking code or it prevents overrides later down the stack.<br><br>
- RHEL5 wants audit rules to start with &quot;exit,always&quot;; RHEL6 wants them to<br>
start with &quot;always,exit&quot;.  Note that some of the actual RHEL6 benchmark<br>
content checks for both (e.g. adjtimex), while some (the majority) does not<br>
(e.g. chmod).<br><br>-&gt; This was a change in auditd itself. &quot;exit,always&quot; is no longer valid.<br><br>Trevor<br><br><div class="gmail_quote">On Tue, Feb 26, 2013 at 10:05 AM, Shaw, Ray V CTR (US) <span dir="ltr">&lt;<a href="mailto:ray.v.shaw.ctr@mail.mil" target="_blank">ray.v.shaw.ctr@mail.mil</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Classification: UNCLASSIFIED<br>
Caveats: NONE<br>
<br>
&gt; The ticketing system shows me you&#39;d opened up a bunch of tickets to add<br>
&gt; a &quot;New rule&quot; for items which were in the old RHEL 5 USGCB profile.<br>
&gt; Okay, great, this helps with ensuring there is continuation of that<br>
&gt; profile/baseline with some consistency.<br>
<br>
I haven&#39;t opened any of these myself, but I did have a question along a<br>
similar line.  Some things clash between the RHEL5 and RHEL6 STIG, which I&#39;m<br>
discovering after having made my RHEL6 systems mostly-RHEL5-STIG-compliant and<br>
now starting on the RHEL6 STIG in earnest (I was just picking off items<br>
before).  Specifically:<br>
<br>
- RHEL5 wants /etc/shadow to be 0400; RHEL6 wants this and /etc/gshadow at<br>
0000.  Not sure of the advantage of the latter.<br>
- RHEL5 wants module loading (DCCP, SCTP, Bluetooth, etc.) disabled with<br>
/bin/true; RHEL6 wants /bin/false.<br>
- RHEL5 wants audit rules to start with &quot;exit,always&quot;; RHEL6 wants them to<br>
start with &quot;always,exit&quot;.  Note that some of the actual RHEL6 benchmark<br>
content checks for both (e.g. adjtimex), while some (the majority) does not<br>
(e.g. chmod).<br>
<br>
I&#39;m not sure what the level of interest is in making these agree.  It would<br>
certainly help folks like me at the moment, who are uncertain which STIG might<br>
be used to evaluate RHEL6 systems while the RHEL6 STIG is still in draft<br>
status*.  It would actually continue to help me down the road, due to<br>
simplified Puppet content (e.g. if I can have one /etc/modprobe.d/stig.conf<br>
file for both RHEL5 and RHEL6, yay).<br>
<br>
I haven&#39;t submitted anything to DISA regarding these; I focused there on items<br>
where I&#39;d like to see the actual intent of the STIG change, and these are<br>
mostly just syntax.  If there is consensus that the RHEL6 STIG should match<br>
the RHEL5 STIG, I&#39;d be happy to try to do the work on (at least some of)<br>
these, because I&#39;ve been wanting to start contributing and well, that seems<br>
like an easy start.  In particular, since some of the audit checks already<br>
accept both sets of syntax, I would love to be able to make the rest do so as<br>
well (though I&#39;m not sure how important it is for the prose to reflect this;<br>
currently, it doesn&#39;t).<br>
<br>
--<br>
Ray Shaw<br>
Contractor, STG<br>
Unix support, Army Research Labs<br>
<br>
* While the 2nd and 3rd points are just syntax, and could be explained to an<br>
inspection team as the system actually being compliant, it makes SCAP scan<br>
results look bad for one or the other, and I suspect will result in (at least<br>
here) a small pile of extra documentation.  It is also possible that an<br>
inspector could mark such an item as a failure.<br>
<br>
Classification: UNCLASSIFIED<br>
Caveats: NONE<br>
<br>
<br>
<br>_______________________________________________<br>
scap-security-guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Trevor Vaughan<br>Vice President, Onyx Point, Inc<br>(410) 541-6699<br><a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br><br>-- This account not approved for unencrypted proprietary information --