[PATCH] [RFC] Creating shared bash script directory

Jan Lieskovsky jlieskov at redhat.com
Wed Dec 4 10:13:22 UTC 2013


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?

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

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