----- Original Message -----
From: "Shawn Wells" <shawn(a)redhat.com>
To: scap-security-guide(a)lists.fedorahosted.org
Sent: Friday, December 6, 2013 5:56:56 AM
Subject: Re: [PATCH] [RFC] Creating shared bash script directory
On 12/5/13, 9:29 AM, Jan Lieskovsky wrote:
> Hi Shawn,
>
> ----- Original Message -----
>> From: "Shawn Wells" <shawn(a)redhat.com>
>> To: scap-security-guide(a)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(a)redhat.com>
>>>> To: scap-security-guide(a)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(a)redhat.com>
>>>>> To: scap-security-guide(a)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).
Yeah, multiple rows seem reasonable. Thanks.
Regarding the form of red_id="" used in the attestation, could we
agree on format for it (right now it's just date, would we want
something like ref_id="fed_20131206" or ref_id="el6_20131206"?
Asking because if one day we reach the state each of the attestations
will have an testing script associated with it, so there would be
a way how to distinguish the platform?
Or should it be yet ref_id="fed_ntpd_20131206" to be more exact?
(IOW to have chance to provide more attestations per day)
> 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.
Sounds reasonable. Will you open it or should I? :) (with my existing
proposal)
>> 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 :)
OK. Reasonable again.
>> 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.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide