[RFC] Manual Profile Use

Jeffrey Blank blank at eclipse.ncsc.mil
Tue Aug 14 14:59:16 UTC 2012


Yes -- please make a Profile -- that's exactly why the project was laid
out the way it was.

If you check out RHEL6/transforms/xccdf-addprofile.xslt (and I suspect
you have already) you'll see how they are added into the full content.
Relatedly, if an agency/entity wanted to issue a baseline using the
content (and perhaps only include their own Profile and selected Rules
in the XCCDF, we'll make more XSLT to transform accordingly).

I believe we are basically aligned with regard to upstream/forking, and
again again I am very much less concerned about remediation and forking
than maintaining forward progress of the project at this time, to
address necessary changes that were identified at the recent meeting.

Along those lines, please expect a patch for many of the file
permissions (consistent with the strategy documented here
https://fedorahosted.org/scap-security-guide/wiki/STIGfileperms) later
today.

That wiki page is meant to be a discussion, not any kind of edict.  But
it was put together quite intentionally.  There needs to be some kind of
strategy/criteria/justification for caring about certain files, since
"comprehensive" is impossible and attempts to get there are laughable.
We cannot end up with a giant (seemingly random) selection of files and
directories that introduces cost exceeding benefit (and half-clever
admins will still be able to get away with permissions mischief anyway).
 At some point, less becomes more (and we may already be past it).  It
is also important to think of this as a software project that has a
support/maintenance tail with costs.



On 08/14/2012 09:41 AM, Spencer R. Shimko wrote:
> On 8/14/12 8:49 AM, "Steve Grubb" <sgrubb at redhat.com> wrote:
> 
>> On Tuesday, August 14, 2012 04:29:39 AM Spencer R. Shimko wrote:
>>> Our patches, if necessary, will always be additive.  We will always
>>> engage
>>> the relevant community first.  Hence this RFC.  *We are not forking*.
>>> Quite to the contrary, we learned from Red Hat.  Red Hat carries
>>> countless
>>> patches to upstream repositories.  They include those patches in source
>>> RPMs.  You don't consider those packages containing patches forks do you
>>> Shawn?
>>
>> We have an upstream first policy. We find problems, talk with upstream
>> about the 
>> problem, submit patches that are acceptable by upstream, only then do we
>> patch 
>> an old release that we want some stability in. We re-base to a current
>> release 
>> that allows us to drop patches when convenient.
> 
> I'm not sure why you are raising this point.  I clearly stated that we
> will communicate with upstream first very clearly:
> "We will always engage the relevant community first."
> 
> Thanks though,
> --Spencer
> 
>>
>> -Steve
> 
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


More information about the scap-security-guide mailing list