[PATCH] [RFC] Creating shared bash script directory

Shawn Wells shawn at redhat.com
Fri Dec 6 04:56:56 UTC 2013


On 12/5/13, 9:29 AM, Jan Lieskovsky wrote:
> Hi Shawn,
>
> ----- Original Message -----
>> From: "Shawn Wells" <shawn at redhat.com>
>> To: scap-security-guide at lists.fedorahosted.org
>> Sent: Thursday, December 5, 2013 8:33:17 AM
>> Subject: Re: [PATCH] [RFC] Creating shared bash script directory
>>
>> On 12/4/13, 5:13 AM, Jan Lieskovsky wrote:
>>> Hello Shawn,
>>>
>>>     just to known the current status of this one..
>>>
>>> Are we waiting for wider feedback from other participants
>>> of this mailing list for their opinion prior going ahead
>>> implementing this?
>>>
>>> Or should I first look what would need to be changed (and
>>> come with a proposal how to fix) wrt to RPM packages building
>>> from new scheme prior actually starting using your proposal?
>> Many of us are just getting back online after the US holidays, so
>> apologies for the delay. I did want to give others a chance to chime in
>> though.
> Thank you. No worries (understandable).
>
>> A few comments in-line below.
>>
>>> ----- Original Message -----
>>>> From: "Jan Lieskovsky" <jlieskov at redhat.com>
>>>> To: scap-security-guide at lists.fedorahosted.org
>>>> Sent: Tuesday, December 3, 2013 10:59:58 AM
>>>> Subject: Re: [PATCH] [RFC] Creating shared bash script directory
>>>>
>>>> ----- Original Message -----
>>>>> From: "Shawn Wells" <shawn at redhat.com>
>>>>> To: scap-security-guide at lists.fedorahosted.org
>>>>> Sent: Tuesday, December 3, 2013 5:56:48 AM
>>>>> Subject: Re: [PATCH] [RFC] Creating shared bash script directory
>>>>>
>>>>> On 12/2/13, 7:42 AM, Jan Lieskovsky wrote:
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> >From 3ad8ce28808123fb2d66db09afb98a3b7fd105b4 Mon Sep 17 00:00:00 2001
>>>>>
>>>>>
>>>>>
>>>>>> From: Shawn Wells <shawn at redhat.com> > Date: Fri, 29 Nov 2013
>>>>>> 23:48:16
>>>>>> -0500 > Subject: [PATCH] [RFC] Creating shared bash script directory
>>>>>
>>>>>> As remediation content expands, many scripts will be repurposed across
>>>>>> operating system releases. To reduce > the maintanence burden of having
>>>>>> the same script in multiple places, I propose to create a shared fix
>>>>>> directory. A patch to demonstrate this concept is attached.
>>>>> This is a great idea.
>>>>>
>>>>>
>>>>>
>>>>>> combinefixes was modified to first look at input/fixes/bash, then .. /
>>>>>> shared/fixes / , else echo a "no fix exists" message.
>>>>>
>>>>>> The downside to this approach is "exclusion" -- just because a script
>>>>>> does
>>>>>> not exist within RHEL6/fixes/bash does not > automatically mean we want
>>>>>> the .. / shared/fixes / version. Unsure how to handle this. One idea was
>>>>>> to 'touch RHEL6/fixes/bash', > and then delete that file if the shared
>>>>>> version was to be inherited.
>>>>> How about to keep the shared fixes scripts as proposed, but have
>>>>> combinefixes
>>>>> unmodified? IOW
>>>>> when the fix should be included, we would create just symlink from the
>>>>> shared
>>>>> directory
>>>>> to particular product fixes directory (no symlink => fix isn't included).
>>>>> And
>>>>> add some README
>>>>> file in the shared directory documenting this practice (IOW when adding
>>>>> new
>>>>> fixes the
>>>>> contributor to consider if the fix is universal enough and could be
>>>>> re-used
>>>>> also in
>>>>> other product).
>>>>>
>>>>> That's completely common sensical.
>>>>>
>>>>> What are your thoughts on doing this for OVAL as well? We'd need to
>>>>> update
>>>>> the platform tags, however that's much simpler than retaining multiple
>>>>> copies of the core OVAL.
>>>> Was thinking about OVAL checks too - I think it would make sense to share
>>>> OVAL
>>>> checks as much as possible also. Two cases can happen (I can quickly think
>>>> of):
>>>>
>>>> * just platform would differ - we could handle this via XSLT
>>>> transformation
>>>> during
>>>>     the Makefile stage for product (IOW the shared version would have some
>>>>     placeholder,
>>>>     evaluated during build of the content to one of RHEL6 / Fedora 19
>>>>     etc.),
>> I really like your idea of XSLT. To expand upon this, perhaps we could
>> write logic into the XSLT that would verify the OVAL has received
>> test_attestation for the associated platform.
> I think this is another great proposal.
>
>> For example:
>>> <definition class="compliance" id="umask_for_daemons" version="1">
>>>      <metadata>
>>>        <title>Set Daemon umask</title>
>>>        <affected family="unix">
>>>          <platform>Red Hat Enterprise Linux 6</platform>
> For the initial version I will replace platform value with
> system_name in the XSLT transform for the beginning. Should we find
> better way how to reference it, it can be changed later yet.
>
>>>        </affected>
>>>        <description>The daemon umask should be set as
>>>        appropriate</description>
>>>        <reference source="swells" ref_id="20130901"
>>> ref_url="test_attestation" />
>>>      </metadata>
>>>      <criteria>
>>>        <criterion test_ref="test_umask_for_daemons" />
>>>      </criteria>
>>>    </definition>
>> I propose we extend the <reference> tag, to something similar to:
>> <reference source="swells" ref_id="20130901" ref_url="test_attestation"
>> platform="RHEL6" />
> And if the check should be for more platforms, there would be multiple
> platform="" attributes or multiple 'reference' rows?

It's likely that differing individuals will submit test_attestation for 
different platforms. For example, as you port OVAL to Fedora, it's 
likely you'll be retesting existing RHEL6 content which is already 
tagged by Jeff/Dave/Maura/myself/others. So I'd say multiple rows (if 
feasible).


> Besides that (maybe subject for another thread again), since the test
> attestations seems to have unique identifiers already, would we want
> to save the content / scenario, that have been performed within that
> testing? Meaning the exact list of commands, that have been executed
> (together with possible configuration changes if involved), so person
> performing attestation (again) later (in case check got enhanced) could
> run that steps / scenario again (still manually) to ensure no regression
> was introduced? Would we want to keep this information within scap-security-guide
> Git repository or in some new Git repository? SSG-tests or SCAP-tests?
>
> This would be one set of tests to be performed, and hopefully in the
> future we will come with a way how automated testing could be performed
> too (so from this perspective having this testing information stored
> [if agreed to] in separate repository would make more sense).

This is an incredibly important area. There's been many discussions on 
unit testing -- lets save this for a new thread.

>> The XSLT would check for test_attestation against platform=RHEL6, and if
>> so, continue the build. If the Make was running against Fedora, the
>> build would fail with an error similar to "Error: No test_attestation
>> for umask_for_daemons against Fedora 19"
> I can see the benefit here. Also this somehow concludes we (I) should
> start creating attestations for Fedora rules :) (or maybe wait and
> do it later when we merged the content and provide them only once
> tested on Fedora).

IMO, wait until the merge :)

>> We'd probably want some developer level flag to override this though,
>> for non-RPM builds that the development community runs on their local
>> systems.
> This should be possible to implement too. Looks like another great proposal.
> Agree.
>
>>>> * whole OVAL check would differ (examples SysV Init vs systemd) - in this
>>>> case
>>>>     each of the products would have its own OVAL implementation at
>>>>     appropriate
>>>>     place.
>> Yes, precisely!
>>
>>
>>>> I think this proposal is elastic enough to allow us to have shared
>>>> definitions
>>>> on one side (symlinks to shared code case), and also deal with
>>>> particularities
>>>> of a specific product (instead of symlink it would have the OVAL
>>>> definition /
>>>> remediation script implementation on expected place for that product).
>>>>
>>>> To get this working we would need yet slightly to modify the way how RPMs
>>>> are
>>>> created for both of RHEL / Fedora (include the shared directory etc.), but
>>>> (I think) the advantages / simplification this concept brings are worthy
>>>> the
>>>> effort.



More information about the scap-security-guide mailing list