----- 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).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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.
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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@redhat.com To: scap-security-guide@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@redhat.com To: scap-security-guide@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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" jlieskov@redhat.com To: scap-security-guide@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@redhat.com To: scap-security-guide@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.),
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
Hi Shawn,
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org 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" jlieskov@redhat.com To: scap-security-guide@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@redhat.com To: scap-security-guide@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.),
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?
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).
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).
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
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 12/5/13, 9:29 AM, Jan Lieskovsky wrote:
Hi Shawn,
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org 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" jlieskov@redhat.com To: scap-security-guide@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@redhat.com To: scap-security-guide@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.),
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).
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.
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 :)
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.
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org 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" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org 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" jlieskov@redhat.com To: scap-security-guide@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@redhat.com To: scap-security-guide@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.),
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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jan Lieskovsky -
Shawn Wells