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.
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.
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>
</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" />
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"
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.
* 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
