[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