[PATCH] [RFC] Creating shared bash script directory

Jan Lieskovsky jlieskov at redhat.com
Tue Dec 3 09:59:58 UTC 2013


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

* 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
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> 


More information about the scap-security-guide mailing list