[PATCH] [RFC] Creating shared bash script directory

Shawn Wells shawn at redhat.com
Thu Dec 5 07:33:17 UTC 2013


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.

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.

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>
>       </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" />

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"

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.

>>
>> * 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.
>>
>> Thank you && Regards, Jan.
>> --
>> Jan iankko Lieskovsky / Red Hat Security Technologies Team



More information about the scap-security-guide mailing list