note for the USGCB tickets (UNCLASSIFIED)

Trevor Vaughan tvaughan at onyxpoint.com
Tue Feb 26 17:55:26 UTC 2013


- 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 at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>


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

-- This account not approved for unencrypted proprietary information --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130226/95b24f91/attachment.html>


More information about the scap-security-guide mailing list