----- 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.), * 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. 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
