----- Original Message ----- > From: "Shawn Wells" <[email protected]> > To: [email protected] > 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" <[email protected]> > >> To: [email protected] > >> 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" <[email protected]> > >>>> To: [email protected] > >>>> Sent: Tuesday, December 3, 2013 10:59:58 AM > >>>> Subject: Re: [PATCH] [RFC] Creating shared bash script directory > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Shawn Wells" <[email protected]> > >>>>> To: [email protected] > >>>>> 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
