Re: Ansible vs bash fixup scripts

[Marek Haicman]

On 01/06/2018 04:36 PM, Olivier BONHOMME wrote:



Le 12/12/2017 à 19:09, Marek Haicman a écrit :

Hi Chuck,
it's definitely not like we are moving away from bash remediations
towards Ansible. As the remediation during scan is still bash-only, bash
is still important part of SSG. It's true that in upstream SSG we tried
to get Ansible to parity with bash, and it's even true that in some
cases Ansible remediation is easier to make, thus is implemented first.

Basically - it's more about resources available, and not much about our
agenda. And with Ansible remediations on par with bash, we should be
able to fix both.

Regards,
Marek



Hello Marek,

As a newbie into the SSG community, there are things about fixes that
are not very clear to me.

You said that remediations are bash-only. However, when I look at the
DS/XCCDF+OVAL files generated, I can see that for some rules, there are
only ansible fixes and no bash fixes.

And when I did some tests on my side, I realized that some remediations
were in error because ansible wasn't installed or because I had an old
version of ansible.

SSG guys seems to say there is always a bash fallback as it has been
discussed here :
https://github.com/OpenSCAP/scap-security-guide/issues/2467.

But when I see the generated file, I wonder how it can be possible. So
is it possible to clarify the following questions :
  - Is ansible mandatory for some remediations ?
  - If yes, is it possible to provide the minimum version needed for
applying the remediations into a correct way.
  - Does oscap really fallback to bash when ansible fails ? If yes, how
does it work ?

Thanks again for the answers.

Regards,
Olivier Bonhomme



Hi Olivier,
there's no such complexity. If you run `oscap xccdf eval ... --remediate 
...`, it will perform bash remediation. There is no way to run ansible 
or any other snippets during this "scanner remediation".


Missing bash remediations, where ansible remediation is available might 
be because of already available ansible module, which makes it much 
easier to create ansible fix, than to write sensible bash. But it's 
definitely not a state we want to end with. Our goal is to have 
remediations for all rules that makes sense to remediate. Currently to 
have complete coverage in combination of anaconda (that's small subset 
of all rules needs to be covered during installation) + bash, and 
anaconda + ansible. We want both combinations to yield full results. 
Unfortunately we are not there, yet.


So to answer the questions:
 - ansible might be currently the only option, but it's not design 
decision but result of missing bash (basically a bug)
 - that's something we should look into, at least have it in the 
comment section - I have created an issue: 
https://github.com/OpenSCAP/openscap/issues/945

 - nope, you would have to run both manually :)

Hope it makes sense,
Marek
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Olivier BONHOMME]

Le 12/12/2017 à 19:09, Marek Haicman a écrit :
> Hi Chuck,
> it's definitely not like we are moving away from bash remediations
> towards Ansible. As the remediation during scan is still bash-only, bash
> is still important part of SSG. It's true that in upstream SSG we tried
> to get Ansible to parity with bash, and it's even true that in some
> cases Ansible remediation is easier to make, thus is implemented first.
> 
> Basically - it's more about resources available, and not much about our
> agenda. And with Ansible remediations on par with bash, we should be
> able to fix both.
> 
> Regards,
> Marek
> 

Hello Marek,

As a newbie into the SSG community, there are things about fixes that
are not very clear to me.

You said that remediations are bash-only. However, when I look at the
DS/XCCDF+OVAL files generated, I can see that for some rules, there are
only ansible fixes and no bash fixes.

And when I did some tests on my side, I realized that some remediations
were in error because ansible wasn't installed or because I had an old
version of ansible.

SSG guys seems to say there is always a bash fallback as it has been
discussed here :
https://github.com/OpenSCAP/scap-security-guide/issues/2467.

But when I see the generated file, I wonder how it can be possible. So
is it possible to clarify the following questions :
 - Is ansible mandatory for some remediations ?
 - If yes, is it possible to provide the minimum version needed for
applying the remediations into a correct way.
 - Does oscap really fallback to bash when ansible fails ? If yes, how
does it work ?

Thanks again for the answers.

Regards,
Olivier Bonhomme



___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

RE: [Non-DoD Source] Re: Ansible vs bash fixup scripts

[Paige, David B CTR USARMY ICOE (US)]

Thanks.  I hope you are able to get the scripts included into the SSG.  I 
didn't know how to do github contributions until it was posted earlier in this 
thread.


David Paige, CISSP
USAICoE CIO/G6, Contractor
Sr. Systems Engineer II
520-533-6213
david.b.paige@mail.mil

-Original Message-
From: Pellitt, Chad CIV CDSA Dam Neck, R21 [mailto:chad.pell...@navy.mil] 
Sent: Friday, December 15, 2017 10:05 AM
To: SCAP Security Guide <scap-security-guide@lists.fedorahosted.org>
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  






The scripts have been uploaded here:
Caution-https://github.com/OpenSCAP/scap-security-guide/issues/2494

Chad Pellitt
CDSA Dam Neck R21
chad.pell...@navy.mil

From: Marek Haicman [mhaic...@redhat.com]
Sent: Friday, December 15, 2017 4:59 AM
To: scap-security-guide@lists.fedorahosted.org
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

Hello Chad,
it would be terrific to have these scripts available in SSG. I understand it 
takes time to make first code contribution, so this should be sufficient:
* create an account on github.com
* open issue on SSG project
Caution-https://github.com/OpenSCAP/scap-security-guide/issues
* attach bash scripts to the issue

Then someone else can start moving these to the project itself. Maybe with 
step-by-step list, so you can jump in as well.

Thanks!
Marek

On 12/15/2017 12:11 AM, Pellitt, Chad CIV CDSA Dam Neck, R21 wrote:
> I have 264 bash scripts, compared to the 168 that are in the rhel7 and shared 
> bash fix directories for the SSG. I have tested and deployed systems with 
> them. Is there a good place to upload these, if anyone wants to take a look? 
> If it helps these can be contributed to the SSG, but I am not familiar with 
> how contributing to an open source project works.
>
> The scripts are already using the SSG rule names, as I generally consume them 
> by cloning the latest SSG, copying them into the fixes directory, and 
> building. I did a few things differently, which I am not sure would be 
> entirely welcome. For example, the scripts create a backup of files that are 
> being modified. This is not required, but I like to do it.
>
> Chad Pellitt
> CDSA Dam Neck R21
> chad.pell...@navy.mil
> 
> From: Gabe Alford [redhatri...@gmail.com]
> Sent: Thursday, December 14, 2017 2:29 PM
> To: SCAP Security Guide
> Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts
>
> Chuck,
>
> I completely understand your frustrations. SSG is evolving to handle 
> different types of remediation languages for consumption by environments that 
> may use different remediation technologies like puppet, ansible, etc. besides 
> just bash.
> By default, oscap does only bash remediations. One of the issues that we have 
> is a lack of resources and help to address some of your concerns and 
> frustrations.
> More contributions from the community (bash, ansible, OVAL, etc.) to close 
> the gap in the content would really go a long way to providing fully complete 
> content that the majority of users would be happy with.
> If anything in my mind, this is a great call to our SSG community to 
> (hopefully) re-engage and help close the gap in the content by submitting PRs 
> with enhancements and fixes. It could be as simple as providing a single file 
> with all the bash remediations in a PR that the core contributors could merge 
> into the SSG structure if a contributor doesn't have the time to do it 
> themselves.
>
> Gabe
>
> On Tue, Dec 12, 2017 at 2:10 PM, Chuck Atkins 
> <chuck.atk...@kitware.com<Caution-mailto:chuck.atk...@kitware.com>> wrote:
> My "awking" was a little off so a few of those do have bash content but most 
> do not.
>
> The audit and dconf rules were the most problematic to deal with.  The audit 
> rules because I (and I'm sure I'm not alone here) tend to find them very 
> opaque cryptic. so manually fixing them can be rough.  The dconf rules are 
> confusing mainly because the description explicitly refers to a particular 
> file to put settings in while the bash content for other dconf settings seem 
> to create an SCAP Security Guide specific config file (i.e. 
> /etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why 
> that's certainly valid but it's confusing to have the prose refer to 
> addressing the issue in one file while the fix scripts address it in a 
> different file.
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing Kitware, 

Re: Ansible vs bash fixup scripts

[Pellitt, Chad CIV CDSA Dam Neck, R21]

The scripts have been uploaded here:
https://github.com/OpenSCAP/scap-security-guide/issues/2494

Chad Pellitt
CDSA Dam Neck R21
chad.pell...@navy.mil

From: Marek Haicman [mhaic...@redhat.com]
Sent: Friday, December 15, 2017 4:59 AM
To: scap-security-guide@lists.fedorahosted.org
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

Hello Chad,
it would be terrific to have these scripts available in SSG. I
understand it takes time to make first code contribution, so this should
be sufficient:
* create an account on github.com
* open issue on SSG project
https://github.com/OpenSCAP/scap-security-guide/issues
* attach bash scripts to the issue

Then someone else can start moving these to the project itself. Maybe
with step-by-step list, so you can jump in as well.

Thanks!
Marek

On 12/15/2017 12:11 AM, Pellitt, Chad CIV CDSA Dam Neck, R21 wrote:
> I have 264 bash scripts, compared to the 168 that are in the rhel7 and shared 
> bash fix directories for the SSG. I have tested and deployed systems with 
> them. Is there a good place to upload these, if anyone wants to take a look? 
> If it helps these can be contributed to the SSG, but I am not familiar with 
> how contributing to an open source project works.
>
> The scripts are already using the SSG rule names, as I generally consume them 
> by cloning the latest SSG, copying them into the fixes directory, and 
> building. I did a few things differently, which I am not sure would be 
> entirely welcome. For example, the scripts create a backup of files that are 
> being modified. This is not required, but I like to do it.
>
> Chad Pellitt
> CDSA Dam Neck R21
> chad.pell...@navy.mil
> 
> From: Gabe Alford [redhatri...@gmail.com]
> Sent: Thursday, December 14, 2017 2:29 PM
> To: SCAP Security Guide
> Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts
>
> Chuck,
>
> I completely understand your frustrations. SSG is evolving to handle 
> different types of remediation languages for consumption by environments that 
> may use different remediation technologies like puppet, ansible, etc. besides 
> just bash.
> By default, oscap does only bash remediations. One of the issues that we have 
> is a lack of resources and help to address some of your concerns and 
> frustrations.
> More contributions from the community (bash, ansible, OVAL, etc.) to close 
> the gap in the content would really go a long way to providing fully complete 
> content that the majority of users would be happy with.
> If anything in my mind, this is a great call to our SSG community to 
> (hopefully) re-engage and help close the gap in the content by submitting PRs 
> with enhancements and fixes. It could be as simple as providing
> a single file with all the bash remediations in a PR that the core 
> contributors could merge into the SSG structure if a contributor doesn't have 
> the time to do it themselves.
>
> Gabe
>
> On Tue, Dec 12, 2017 at 2:10 PM, Chuck Atkins 
> <chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>> wrote:
> My "awking" was a little off so a few of those do have bash content but most 
> do not.
>
> The audit and dconf rules were the most problematic to deal with.  The audit 
> rules because I (and I'm sure I'm not alone here) tend to find them very 
> opaque cryptic. so manually fixing them can be rough.  The dconf rules are 
> confusing mainly because the description explicitly refers to a particular 
> file to put settings in while the bash content for other dconf settings seem 
> to create an SCAP Security Guide specific config file (i.e. 
> /etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why 
> that's certainly valid but it's confusing to have the prose refer to 
> addressing the issue in one file while the fix scripts address it in a 
> different file.
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman 
> <mhaic...@redhat.com<mailto:mhaic...@redhat.com>> wrote:
> Crossreferencing with my attempt to remediate basically fresh RHEL7 
> installation, these are rules from your list that are in my OSPP-hardened 
> system marked as failing:
>
> audit_rules_privileged_commands
> firewalld_sshd_port_enabled
>
> So using also ansible won't help you much.
>
>
>
> On 12/12/2017 09:35 PM, Chuck Atkins wrote:
> Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following rules 
> with only ansible fixes:
>
> accounts_root_path_dirs_no_write
> audit_rules_dac_modification_fchmod
> audit_rules_dac_modification_fchown
> audit_rules_privileged_commands
> audit

Re: Ansible vs bash fixup scripts

[Matthew]

That's all we have to do to submit code? I would've done that ages ago.

On Dec 15, 2017 4:59 AM, "Marek Haicman" <mhaic...@redhat.com> wrote:

> Hello Chad,
> it would be terrific to have these scripts available in SSG. I understand
> it takes time to make first code contribution, so this should be sufficient:
> * create an account on github.com
> * open issue on SSG project https://github.com/OpenSCAP/sc
> ap-security-guide/issues
> * attach bash scripts to the issue
>
> Then someone else can start moving these to the project itself. Maybe with
> step-by-step list, so you can jump in as well.
>
> Thanks!
> Marek
>
> On 12/15/2017 12:11 AM, Pellitt, Chad CIV CDSA Dam Neck, R21 wrote:
>
>> I have 264 bash scripts, compared to the 168 that are in the rhel7 and
>> shared bash fix directories for the SSG. I have tested and deployed systems
>> with them. Is there a good place to upload these, if anyone wants to take a
>> look? If it helps these can be contributed to the SSG, but I am not
>> familiar with how contributing to an open source project works.
>>
>> The scripts are already using the SSG rule names, as I generally consume
>> them by cloning the latest SSG, copying them into the fixes directory, and
>> building. I did a few things differently, which I am not sure would be
>> entirely welcome. For example, the scripts create a backup of files that
>> are being modified. This is not required, but I like to do it.
>>
>> Chad Pellitt
>> CDSA Dam Neck R21
>> chad.pell...@navy.mil
>> ________
>> From: Gabe Alford [redhatri...@gmail.com]
>> Sent: Thursday, December 14, 2017 2:29 PM
>> To: SCAP Security Guide
>> Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts
>>
>> Chuck,
>>
>> I completely understand your frustrations. SSG is evolving to handle
>> different types of remediation languages for consumption by environments
>> that may use different remediation technologies like puppet, ansible, etc.
>> besides just bash.
>> By default, oscap does only bash remediations. One of the issues that we
>> have is a lack of resources and help to address some of your concerns and
>> frustrations.
>> More contributions from the community (bash, ansible, OVAL, etc.) to
>> close the gap in the content would really go a long way to providing fully
>> complete content that the majority of users would be happy with.
>> If anything in my mind, this is a great call to our SSG community to
>> (hopefully) re-engage and help close the gap in the content by submitting
>> PRs with enhancements and fixes. It could be as simple as providing
>> a single file with all the bash remediations in a PR that the core
>> contributors could merge into the SSG structure if a contributor doesn't
>> have the time to do it themselves.
>>
>> Gabe
>>
>> On Tue, Dec 12, 2017 at 2:10 PM, Chuck Atkins <chuck.atk...@kitware.com
>> <mailto:chuck.atk...@kitware.com>> wrote:
>> My "awking" was a little off so a few of those do have bash content but
>> most do not.
>>
>> The audit and dconf rules were the most problematic to deal with.  The
>> audit rules because I (and I'm sure I'm not alone here) tend to find them
>> very opaque cryptic. so manually fixing them can be rough.  The dconf rules
>> are confusing mainly because the description explicitly refers to a
>> particular file to put settings in while the bash content for other dconf
>> settings seem to create an SCAP Security Guide specific config file (i.e.
>> /etc/dconf/db/local.d/10-scap-security-guide for example).  I can see
>> why that's certainly valid but it's confusing to have the prose refer to
>> addressing the issue in one file while the fix scripts address it in a
>> different file.
>>
>> --
>> Chuck Atkins
>> Staff R Engineer, Scientific Computing
>> Kitware, Inc.
>>
>>
>> On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman <mhaic...@redhat.com
>> <mailto:mhaic...@redhat.com>> wrote:
>> Crossreferencing with my attempt to remediate basically fresh RHEL7
>> installation, these are rules from your list that are in my OSPP-hardened
>> system marked as failing:
>>
>> audit_rules_privileged_commands
>> firewalld_sshd_port_enabled
>>
>> So using also ansible won't help you much.
>>
>>
>>
>> On 12/12/2017 09:35 PM, Chuck Atkins wrote:
>> Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following
>> rules with only ansible fixes:
>>
>> a

Re: Ansible vs bash fixup scripts

[Marek Haicman]

Hello Chad,
it would be terrific to have these scripts available in SSG. I 
understand it takes time to make first code contribution, so this should 
be sufficient:

* create an account on github.com
* open issue on SSG project 
https://github.com/OpenSCAP/scap-security-guide/issues

* attach bash scripts to the issue

Then someone else can start moving these to the project itself. Maybe 
with step-by-step list, so you can jump in as well.


Thanks!
Marek

On 12/15/2017 12:11 AM, Pellitt, Chad CIV CDSA Dam Neck, R21 wrote:

I have 264 bash scripts, compared to the 168 that are in the rhel7 and shared 
bash fix directories for the SSG. I have tested and deployed systems with them. 
Is there a good place to upload these, if anyone wants to take a look? If it 
helps these can be contributed to the SSG, but I am not familiar with how 
contributing to an open source project works.

The scripts are already using the SSG rule names, as I generally consume them 
by cloning the latest SSG, copying them into the fixes directory, and building. 
I did a few things differently, which I am not sure would be entirely welcome. 
For example, the scripts create a backup of files that are being modified. This 
is not required, but I like to do it.

Chad Pellitt
CDSA Dam Neck R21
chad.pell...@navy.mil

From: Gabe Alford [redhatri...@gmail.com]
Sent: Thursday, December 14, 2017 2:29 PM
To: SCAP Security Guide
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

Chuck,

I completely understand your frustrations. SSG is evolving to handle different 
types of remediation languages for consumption by environments that may use 
different remediation technologies like puppet, ansible, etc. besides just bash.
By default, oscap does only bash remediations. One of the issues that we have 
is a lack of resources and help to address some of your concerns and 
frustrations.
More contributions from the community (bash, ansible, OVAL, etc.) to close the 
gap in the content would really go a long way to providing fully complete 
content that the majority of users would be happy with.
If anything in my mind, this is a great call to our SSG community to 
(hopefully) re-engage and help close the gap in the content by submitting PRs 
with enhancements and fixes. It could be as simple as providing
a single file with all the bash remediations in a PR that the core contributors 
could merge into the SSG structure if a contributor doesn't have the time to do 
it themselves.

Gabe

On Tue, Dec 12, 2017 at 2:10 PM, Chuck Atkins 
<chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>> wrote:
My "awking" was a little off so a few of those do have bash content but most do 
not.

The audit and dconf rules were the most problematic to deal with.  The audit 
rules because I (and I'm sure I'm not alone here) tend to find them very opaque 
cryptic. so manually fixing them can be rough.  The dconf rules are confusing 
mainly because the description explicitly refers to a particular file to put 
settings in while the bash content for other dconf settings seem to create an 
SCAP Security Guide specific config file (i.e. 
/etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why 
that's certainly valid but it's confusing to have the prose refer to addressing 
the issue in one file while the fix scripts address it in a different file.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman 
<mhaic...@redhat.com<mailto:mhaic...@redhat.com>> wrote:
Crossreferencing with my attempt to remediate basically fresh RHEL7 
installation, these are rules from your list that are in my OSPP-hardened 
system marked as failing:

audit_rules_privileged_commands
firewalld_sshd_port_enabled

So using also ansible won't help you much.



On 12/12/2017 09:35 PM, Chuck Atkins wrote:
Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following rules 
with only ansible fixes:

accounts_root_path_dirs_no_write
audit_rules_dac_modification_fchmod
audit_rules_dac_modification_fchown
audit_rules_privileged_commands
audit_rules_privileged_commands_su
audit_rules_privileged_commands_sudo
audit_rules_unsuccessful_file_modification_open
dconf_gnome_banner_enabled
dconf_gnome_disable_automount
dconf_gnome_disable_ctrlaltdel_reboot
dconf_gnome_disable_geolocation
dconf_gnome_disable_restart_shutdown
dconf_gnome_disable_thumbnailers
dconf_gnome_disable_user_admin
dconf_gnome_disable_user_list
dconf_gnome_disable_wifi_create
dconf_gnome_disable_wifi_notification
dconf_gnome_screensaver_lock_delay
dconf_gnome_screensaver_user_info
firewalld_sshd_port_enabled
gnome_gdm_disable_automatic_login
gnome_gdm_disable_guest_login
mount_option_dev_shm_nodev
mount_option_dev_shm_noexec
mount_option_dev_shm_nosuid
mount_option_home_nodev
mount_option_home_nosuid
mount_option_var_tmp_nodev
mount_option_var_tmp_noexec
mount_optio

Re: EXTERNAL: Re: Ansible vs bash fixup scripts

[Albrecht, Thomas C]

I’m sure we’ve had a dozen groups just within my company do it.

Sent from my iPhone

On Dec 14, 2017, at 11:31 PM, Matthew 
<simon...@gmail.com<mailto:simon...@gmail.com>> wrote:

Nice to see I'm not the only one who scripted these things.

On Dec 12, 2017 6:15 PM, "Pellitt, Chad CIV CDSA Dam Neck, R21" 
<chad.pell...@navy.mil<mailto:chad.pell...@navy.mil>> wrote:
I have bash remediation scripts for most of the rules you listed, which I can 
share if you want them. I wrote or modified scripts for all the rules in the 
RHEL 7 DISA STIG profile when it was still in the early stages. That profile 
went through a lot of changes a while back, so most of those rules are in the 
OSPP profile, but not the STIG profile now. The scripts for rules removed from 
the STIG profile have been neglected since then, so they might not exactly 
match the current rule.

Chad Pellitt
CDSA Dam Neck R21
chad.pell...@navy.mil<mailto:chad.pell...@navy.mil>

From: Chuck Atkins [chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>]
Sent: Tuesday, December 12, 2017 4:10 PM
To: SCAP Security Guide
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

My "awking" was a little off so a few of those do have bash content but most do 
not.

The audit and dconf rules were the most problematic to deal with.  The audit 
rules because I (and I'm sure I'm not alone here) tend to find them very opaque 
cryptic. so manually fixing them can be rough.  The dconf rules are confusing 
mainly because the description explicitly refers to a particular file to put 
settings in while the bash content for other dconf settings seem to create an 
SCAP Security Guide specific config file (i.e. 
/etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why 
that's certainly valid but it's confusing to have the prose refer to addressing 
the issue in one file while the fix scripts address it in a different file.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman 
<mhaic...@redhat.com<mailto:mhaic...@redhat.com><mailto:mhaic...@redhat.com<mailto:mhaic...@redhat.com>>>
 wrote:
Crossreferencing with my attempt to remediate basically fresh RHEL7 
installation, these are rules from your list that are in my OSPP-hardened 
system marked as failing:

audit_rules_privileged_commands
firewalld_sshd_port_enabled

So using also ansible won't help you much.



On 12/12/2017 09:35 PM, Chuck Atkins wrote:
Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following rules 
with only ansible fixes:

accounts_root_path_dirs_no_write
audit_rules_dac_modification_fchmod
audit_rules_dac_modification_fchown
audit_rules_privileged_commands
audit_rules_privileged_commands_su
audit_rules_privileged_commands_sudo
audit_rules_unsuccessful_file_modification_open
dconf_gnome_banner_enabled
dconf_gnome_disable_automount
dconf_gnome_disable_ctrlaltdel_reboot
dconf_gnome_disable_geolocation
dconf_gnome_disable_restart_shutdown
dconf_gnome_disable_thumbnailers
dconf_gnome_disable_user_admin
dconf_gnome_disable_user_list
dconf_gnome_disable_wifi_create
dconf_gnome_disable_wifi_notification
dconf_gnome_screensaver_lock_delay
dconf_gnome_screensaver_user_info
firewalld_sshd_port_enabled
gnome_gdm_disable_automatic_login
gnome_gdm_disable_guest_login
mount_option_dev_shm_nodev
mount_option_dev_shm_noexec
mount_option_dev_shm_nosuid
mount_option_home_nodev
mount_option_home_nosuid
mount_option_var_tmp_nodev
mount_option_var_tmp_noexec
mount_option_var_tmp_nosuid
rpm_verify_hashes
sebool_httpd_can_network_connect
sebool_secure_mode
set_password_hashing_algorithm_libuserconf
sshd_disable_rhosts
sshd_enable_x11_forwarding
sssd_memcache_timeout
sssd_offline_cred_expiration
sssd_ssh_known_hosts_timeout


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183<tel:%28518%29%20881-1183><tel:%28518%29%20881-1183>

On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman 
<mhaic...@redhat.com<mailto:mhaic...@redhat.com><mailto:mhaic...@redhat.com<mailto:mhaic...@redhat.com>>
 
<mailto:mhaic...@redhat.com<mailto:mhaic...@redhat.com><mailto:mhaic...@redhat.com<mailto:mhaic...@redhat.com>>>>
 wrote:

On 12/12/2017 07:31 PM, Chuck Atkins wrote:

Hi Marek,

My apologies for the ranting tone, that was not my intent; it's
just been a very frustrating transition with the SSG from RHEL6
+ STIG -> RHEL7 + OSPP since what would easily be a
well-documented single-command process to bring the first into
compliance is not so clear-cut for the second.

 Basically - it's more about resources available, and not
much about
 our agenda. And with Ansible remediations on par with bash, we
 should be able to fix bot

Re: Ansible vs bash fixup scripts

[Matthew]

Nice to see I'm not the only one who scripted these things.

On Dec 12, 2017 6:15 PM, "Pellitt, Chad CIV CDSA Dam Neck, R21" <
chad.pell...@navy.mil> wrote:

> I have bash remediation scripts for most of the rules you listed, which I
> can share if you want them. I wrote or modified scripts for all the rules
> in the RHEL 7 DISA STIG profile when it was still in the early stages. That
> profile went through a lot of changes a while back, so most of those rules
> are in the OSPP profile, but not the STIG profile now. The scripts for
> rules removed from the STIG profile have been neglected since then, so they
> might not exactly match the current rule.
>
> Chad Pellitt
> CDSA Dam Neck R21
> chad.pell...@navy.mil
> 
> From: Chuck Atkins [chuck.atk...@kitware.com]
> Sent: Tuesday, December 12, 2017 4:10 PM
> To: SCAP Security Guide
> Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts
>
> My "awking" was a little off so a few of those do have bash content but
> most do not.
>
> The audit and dconf rules were the most problematic to deal with.  The
> audit rules because I (and I'm sure I'm not alone here) tend to find them
> very opaque cryptic. so manually fixing them can be rough.  The dconf rules
> are confusing mainly because the description explicitly refers to a
> particular file to put settings in while the bash content for other dconf
> settings seem to create an SCAP Security Guide specific config file (i.e.
> /etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why
> that's certainly valid but it's confusing to have the prose refer to
> addressing the issue in one file while the fix scripts address it in a
> different file.
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman <mhaic...@redhat.com
> <mailto:mhaic...@redhat.com>> wrote:
> Crossreferencing with my attempt to remediate basically fresh RHEL7
> installation, these are rules from your list that are in my OSPP-hardened
> system marked as failing:
>
> audit_rules_privileged_commands
> firewalld_sshd_port_enabled
>
> So using also ansible won't help you much.
>
>
>
> On 12/12/2017 09:35 PM, Chuck Atkins wrote:
> Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following
> rules with only ansible fixes:
>
> accounts_root_path_dirs_no_write
> audit_rules_dac_modification_fchmod
> audit_rules_dac_modification_fchown
> audit_rules_privileged_commands
> audit_rules_privileged_commands_su
> audit_rules_privileged_commands_sudo
> audit_rules_unsuccessful_file_modification_open
> dconf_gnome_banner_enabled
> dconf_gnome_disable_automount
> dconf_gnome_disable_ctrlaltdel_reboot
> dconf_gnome_disable_geolocation
> dconf_gnome_disable_restart_shutdown
> dconf_gnome_disable_thumbnailers
> dconf_gnome_disable_user_admin
> dconf_gnome_disable_user_list
> dconf_gnome_disable_wifi_create
> dconf_gnome_disable_wifi_notification
> dconf_gnome_screensaver_lock_delay
> dconf_gnome_screensaver_user_info
> firewalld_sshd_port_enabled
> gnome_gdm_disable_automatic_login
> gnome_gdm_disable_guest_login
> mount_option_dev_shm_nodev
> mount_option_dev_shm_noexec
> mount_option_dev_shm_nosuid
> mount_option_home_nodev
> mount_option_home_nosuid
> mount_option_var_tmp_nodev
> mount_option_var_tmp_noexec
> mount_option_var_tmp_nosuid
> rpm_verify_hashes
> sebool_httpd_can_network_connect
> sebool_secure_mode
> set_password_hashing_algorithm_libuserconf
> sshd_disable_rhosts
> sshd_enable_x11_forwarding
> sssd_memcache_timeout
> sssd_offline_cred_expiration
> sssd_ssh_known_hosts_timeout
>
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
> (518) 881-1183<tel:%28518%29%20881-1183>
>
> On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman <mhaic...@redhat.com
> <mailto:mhaic...@redhat.com> <mailto:mhaic...@redhat.com mhaic...@redhat.com>>> wrote:
>
> On 12/12/2017 07:31 PM, Chuck Atkins wrote:
>
> Hi Marek,
>
> My apologies for the ranting tone, that was not my intent; it's
> just been a very frustrating transition with the SSG from RHEL6
> + STIG -> RHEL7 + OSPP since what would easily be a
> well-documented single-command process to bring the first into
> compliance is not so clear-cut for the second.
>
>  Basically - it's more about resources available, and not
> much about
>  our agenda. And with Ansible remediations on par with bash, we
>  should be able to fix both.
>
&g

Re: Ansible vs bash fixup scripts

[Pellitt, Chad CIV CDSA Dam Neck, R21]

I have 264 bash scripts, compared to the 168 that are in the rhel7 and shared 
bash fix directories for the SSG. I have tested and deployed systems with them. 
Is there a good place to upload these, if anyone wants to take a look? If it 
helps these can be contributed to the SSG, but I am not familiar with how 
contributing to an open source project works.

The scripts are already using the SSG rule names, as I generally consume them 
by cloning the latest SSG, copying them into the fixes directory, and building. 
I did a few things differently, which I am not sure would be entirely welcome. 
For example, the scripts create a backup of files that are being modified. This 
is not required, but I like to do it.

Chad Pellitt
CDSA Dam Neck R21
chad.pell...@navy.mil

From: Gabe Alford [redhatri...@gmail.com]
Sent: Thursday, December 14, 2017 2:29 PM
To: SCAP Security Guide
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

Chuck,

I completely understand your frustrations. SSG is evolving to handle different 
types of remediation languages for consumption by environments that may use 
different remediation technologies like puppet, ansible, etc. besides just bash.
By default, oscap does only bash remediations. One of the issues that we have 
is a lack of resources and help to address some of your concerns and 
frustrations.
More contributions from the community (bash, ansible, OVAL, etc.) to close the 
gap in the content would really go a long way to providing fully complete 
content that the majority of users would be happy with.
If anything in my mind, this is a great call to our SSG community to 
(hopefully) re-engage and help close the gap in the content by submitting PRs 
with enhancements and fixes. It could be as simple as providing
a single file with all the bash remediations in a PR that the core contributors 
could merge into the SSG structure if a contributor doesn't have the time to do 
it themselves.

Gabe

On Tue, Dec 12, 2017 at 2:10 PM, Chuck Atkins 
<chuck.atk...@kitware.com<mailto:chuck.atk...@kitware.com>> wrote:
My "awking" was a little off so a few of those do have bash content but most do 
not.

The audit and dconf rules were the most problematic to deal with.  The audit 
rules because I (and I'm sure I'm not alone here) tend to find them very opaque 
cryptic. so manually fixing them can be rough.  The dconf rules are confusing 
mainly because the description explicitly refers to a particular file to put 
settings in while the bash content for other dconf settings seem to create an 
SCAP Security Guide specific config file (i.e. 
/etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why 
that's certainly valid but it's confusing to have the prose refer to addressing 
the issue in one file while the fix scripts address it in a different file.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman 
<mhaic...@redhat.com<mailto:mhaic...@redhat.com>> wrote:
Crossreferencing with my attempt to remediate basically fresh RHEL7 
installation, these are rules from your list that are in my OSPP-hardened 
system marked as failing:

audit_rules_privileged_commands
firewalld_sshd_port_enabled

So using also ansible won't help you much.



On 12/12/2017 09:35 PM, Chuck Atkins wrote:
Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following rules 
with only ansible fixes:

accounts_root_path_dirs_no_write
audit_rules_dac_modification_fchmod
audit_rules_dac_modification_fchown
audit_rules_privileged_commands
audit_rules_privileged_commands_su
audit_rules_privileged_commands_sudo
audit_rules_unsuccessful_file_modification_open
dconf_gnome_banner_enabled
dconf_gnome_disable_automount
dconf_gnome_disable_ctrlaltdel_reboot
dconf_gnome_disable_geolocation
dconf_gnome_disable_restart_shutdown
dconf_gnome_disable_thumbnailers
dconf_gnome_disable_user_admin
dconf_gnome_disable_user_list
dconf_gnome_disable_wifi_create
dconf_gnome_disable_wifi_notification
dconf_gnome_screensaver_lock_delay
dconf_gnome_screensaver_user_info
firewalld_sshd_port_enabled
gnome_gdm_disable_automatic_login
gnome_gdm_disable_guest_login
mount_option_dev_shm_nodev
mount_option_dev_shm_noexec
mount_option_dev_shm_nosuid
mount_option_home_nodev
mount_option_home_nosuid
mount_option_var_tmp_nodev
mount_option_var_tmp_noexec
mount_option_var_tmp_nosuid
rpm_verify_hashes
sebool_httpd_can_network_connect
sebool_secure_mode
set_password_hashing_algorithm_libuserconf
sshd_disable_rhosts
sshd_enable_x11_forwarding
sssd_memcache_timeout
sssd_offline_cred_expiration
sssd_ssh_known_hosts_timeout


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183<tel:%28518%29%20881-1183>

On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman 
<mhaic...@redhat.com<mailto:mhaic...@redhat.com> 
<mailto:mhaic...@redhat.com<mailto:mh

Re: Ansible vs bash fixup scripts

[Gabe Alford]

Chuck,

I completely understand your frustrations. SSG is evolving to handle
different types of remediation languages for consumption by environments
that may use different remediation technologies like puppet, ansible, etc.
besides just bash.
By default, oscap does only bash remediations. One of the issues that we
have is a lack of resources and help to address some of your concerns and
frustrations.
More contributions from the community (bash, ansible, OVAL, etc.) to close
the gap in the content would really go a long way to providing fully
complete content that the majority of users would be happy with.
If anything in my mind, this is a great call to our SSG community to
(hopefully) re-engage and help close the gap in the content by submitting
PRs with enhancements and fixes. It could be as simple as providing
a single file with all the bash remediations in a PR that the core
contributors could merge into the SSG structure if a contributor doesn't
have the time to do it themselves.

Gabe

On Tue, Dec 12, 2017 at 2:10 PM, Chuck Atkins 
wrote:

> My "awking" was a little off so a few of those do have bash content but
> most do not.
>
> The audit and dconf rules were the most problematic to deal with.  The
> audit rules because I (and I'm sure I'm not alone here) tend to find them
> very opaque cryptic. so manually fixing them can be rough.  The dconf rules
> are confusing mainly because the description explicitly refers to a
> particular file to put settings in while the bash content for other dconf
> settings seem to create an SCAP Security Guide specific config file (i.e.
> /etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why
> that's certainly valid but it's confusing to have the prose refer to
> addressing the issue in one file while the fix scripts address it in a
> different file.
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman 
> wrote:
>
>> Crossreferencing with my attempt to remediate basically fresh RHEL7
>> installation, these are rules from your list that are in my OSPP-hardened
>> system marked as failing:
>>
>> audit_rules_privileged_commands
>> firewalld_sshd_port_enabled
>>
>> So using also ansible won't help you much.
>>
>>
>>
>> On 12/12/2017 09:35 PM, Chuck Atkins wrote:
>>
>>> Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following
>>> rules with only ansible fixes:
>>>
>>> accounts_root_path_dirs_no_write
>>> audit_rules_dac_modification_fchmod
>>> audit_rules_dac_modification_fchown
>>> audit_rules_privileged_commands
>>> audit_rules_privileged_commands_su
>>> audit_rules_privileged_commands_sudo
>>> audit_rules_unsuccessful_file_modification_open
>>> dconf_gnome_banner_enabled
>>> dconf_gnome_disable_automount
>>> dconf_gnome_disable_ctrlaltdel_reboot
>>> dconf_gnome_disable_geolocation
>>> dconf_gnome_disable_restart_shutdown
>>> dconf_gnome_disable_thumbnailers
>>> dconf_gnome_disable_user_admin
>>> dconf_gnome_disable_user_list
>>> dconf_gnome_disable_wifi_create
>>> dconf_gnome_disable_wifi_notification
>>> dconf_gnome_screensaver_lock_delay
>>> dconf_gnome_screensaver_user_info
>>> firewalld_sshd_port_enabled
>>> gnome_gdm_disable_automatic_login
>>> gnome_gdm_disable_guest_login
>>> mount_option_dev_shm_nodev
>>> mount_option_dev_shm_noexec
>>> mount_option_dev_shm_nosuid
>>> mount_option_home_nodev
>>> mount_option_home_nosuid
>>> mount_option_var_tmp_nodev
>>> mount_option_var_tmp_noexec
>>> mount_option_var_tmp_nosuid
>>> rpm_verify_hashes
>>> sebool_httpd_can_network_connect
>>> sebool_secure_mode
>>> set_password_hashing_algorithm_libuserconf
>>> sshd_disable_rhosts
>>> sshd_enable_x11_forwarding
>>> sssd_memcache_timeout
>>> sssd_offline_cred_expiration
>>> sssd_ssh_known_hosts_timeout
>>>
>>>
>>> --
>>> Chuck Atkins
>>> Staff R Engineer, Scientific Computing
>>> Kitware, Inc.
>>> (518) 881-1183
>>>
>>> On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman >> > wrote:
>>>
>>> On 12/12/2017 07:31 PM, Chuck Atkins wrote:
>>>
>>> Hi Marek,
>>>
>>> My apologies for the ranting tone, that was not my intent; it's
>>> just been a very frustrating transition with the SSG from RHEL6
>>> + STIG -> RHEL7 + OSPP since what would easily be a
>>> well-documented single-command process to bring the first into
>>> compliance is not so clear-cut for the second.
>>>
>>>  Basically - it's more about resources available, and not
>>> much about
>>>  our agenda. And with Ansible remediations on par with bash,
>>> we
>>>  should be able to fix both.
>>>
>>>
>>> I'm all about having better, more easily maintained content.
>>>  So, given the current state of things, what is the right way to
>>> use the SSG and it's combined ansible and bash fix content to

Re: Ansible vs bash fixup scripts

[Pellitt, Chad CIV CDSA Dam Neck, R21]

I have bash remediation scripts for most of the rules you listed, which I can 
share if you want them. I wrote or modified scripts for all the rules in the 
RHEL 7 DISA STIG profile when it was still in the early stages. That profile 
went through a lot of changes a while back, so most of those rules are in the 
OSPP profile, but not the STIG profile now. The scripts for rules removed from 
the STIG profile have been neglected since then, so they might not exactly 
match the current rule.

Chad Pellitt
CDSA Dam Neck R21
chad.pell...@navy.mil

From: Chuck Atkins [chuck.atk...@kitware.com]
Sent: Tuesday, December 12, 2017 4:10 PM
To: SCAP Security Guide
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

My "awking" was a little off so a few of those do have bash content but most do 
not.

The audit and dconf rules were the most problematic to deal with.  The audit 
rules because I (and I'm sure I'm not alone here) tend to find them very opaque 
cryptic. so manually fixing them can be rough.  The dconf rules are confusing 
mainly because the description explicitly refers to a particular file to put 
settings in while the bash content for other dconf settings seem to create an 
SCAP Security Guide specific config file (i.e. 
/etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why 
that's certainly valid but it's confusing to have the prose refer to addressing 
the issue in one file while the fix scripts address it in a different file.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman 
<mhaic...@redhat.com<mailto:mhaic...@redhat.com>> wrote:
Crossreferencing with my attempt to remediate basically fresh RHEL7 
installation, these are rules from your list that are in my OSPP-hardened 
system marked as failing:

audit_rules_privileged_commands
firewalld_sshd_port_enabled

So using also ansible won't help you much.



On 12/12/2017 09:35 PM, Chuck Atkins wrote:
Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following rules 
with only ansible fixes:

accounts_root_path_dirs_no_write
audit_rules_dac_modification_fchmod
audit_rules_dac_modification_fchown
audit_rules_privileged_commands
audit_rules_privileged_commands_su
audit_rules_privileged_commands_sudo
audit_rules_unsuccessful_file_modification_open
dconf_gnome_banner_enabled
dconf_gnome_disable_automount
dconf_gnome_disable_ctrlaltdel_reboot
dconf_gnome_disable_geolocation
dconf_gnome_disable_restart_shutdown
dconf_gnome_disable_thumbnailers
dconf_gnome_disable_user_admin
dconf_gnome_disable_user_list
dconf_gnome_disable_wifi_create
dconf_gnome_disable_wifi_notification
dconf_gnome_screensaver_lock_delay
dconf_gnome_screensaver_user_info
firewalld_sshd_port_enabled
gnome_gdm_disable_automatic_login
gnome_gdm_disable_guest_login
mount_option_dev_shm_nodev
mount_option_dev_shm_noexec
mount_option_dev_shm_nosuid
mount_option_home_nodev
mount_option_home_nosuid
mount_option_var_tmp_nodev
mount_option_var_tmp_noexec
mount_option_var_tmp_nosuid
rpm_verify_hashes
sebool_httpd_can_network_connect
sebool_secure_mode
set_password_hashing_algorithm_libuserconf
sshd_disable_rhosts
sshd_enable_x11_forwarding
sssd_memcache_timeout
sssd_offline_cred_expiration
sssd_ssh_known_hosts_timeout


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183<tel:%28518%29%20881-1183>

On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman 
<mhaic...@redhat.com<mailto:mhaic...@redhat.com> 
<mailto:mhaic...@redhat.com<mailto:mhaic...@redhat.com>>> wrote:

On 12/12/2017 07:31 PM, Chuck Atkins wrote:

Hi Marek,

My apologies for the ranting tone, that was not my intent; it's
just been a very frustrating transition with the SSG from RHEL6
+ STIG -> RHEL7 + OSPP since what would easily be a
well-documented single-command process to bring the first into
compliance is not so clear-cut for the second.

 Basically - it's more about resources available, and not
much about
 our agenda. And with Ansible remediations on par with bash, we
 should be able to fix both.


I'm all about having better, more easily maintained content. 
So, given the current state of things, what is the right way to
use the SSG and it's combined ansible and bash fix content to
being a RHEL7 machine into compliance with the OSPP profile?

Thanks.

It was not intention to force (or lead) users to combine those two
ways, so I would suggest to stick to what is more convenient for you
- probably bash.

And you can try to use newest upstream release [1]. It has more
stuff fixed than what was shipped in RHEL7.4. (It looks like there
are ~20 failing rules, and at least 3 of them left failing by
design, RHEL7.4 had ~30 rules failing).

Ho

Re: Ansible vs bash fixup scripts

[Chuck Atkins]

My "awking" was a little off so a few of those do have bash content but
most do not.

The audit and dconf rules were the most problematic to deal with.  The
audit rules because I (and I'm sure I'm not alone here) tend to find them
very opaque cryptic. so manually fixing them can be rough.  The dconf rules
are confusing mainly because the description explicitly refers to a
particular file to put settings in while the bash content for other dconf
settings seem to create an SCAP Security Guide specific config file (i.e.
/etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why
that's certainly valid but it's confusing to have the prose refer to
addressing the issue in one file while the fix scripts address it in a
different file.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman  wrote:

> Crossreferencing with my attempt to remediate basically fresh RHEL7
> installation, these are rules from your list that are in my OSPP-hardened
> system marked as failing:
>
> audit_rules_privileged_commands
> firewalld_sshd_port_enabled
>
> So using also ansible won't help you much.
>
>
>
> On 12/12/2017 09:35 PM, Chuck Atkins wrote:
>
>> Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following
>> rules with only ansible fixes:
>>
>> accounts_root_path_dirs_no_write
>> audit_rules_dac_modification_fchmod
>> audit_rules_dac_modification_fchown
>> audit_rules_privileged_commands
>> audit_rules_privileged_commands_su
>> audit_rules_privileged_commands_sudo
>> audit_rules_unsuccessful_file_modification_open
>> dconf_gnome_banner_enabled
>> dconf_gnome_disable_automount
>> dconf_gnome_disable_ctrlaltdel_reboot
>> dconf_gnome_disable_geolocation
>> dconf_gnome_disable_restart_shutdown
>> dconf_gnome_disable_thumbnailers
>> dconf_gnome_disable_user_admin
>> dconf_gnome_disable_user_list
>> dconf_gnome_disable_wifi_create
>> dconf_gnome_disable_wifi_notification
>> dconf_gnome_screensaver_lock_delay
>> dconf_gnome_screensaver_user_info
>> firewalld_sshd_port_enabled
>> gnome_gdm_disable_automatic_login
>> gnome_gdm_disable_guest_login
>> mount_option_dev_shm_nodev
>> mount_option_dev_shm_noexec
>> mount_option_dev_shm_nosuid
>> mount_option_home_nodev
>> mount_option_home_nosuid
>> mount_option_var_tmp_nodev
>> mount_option_var_tmp_noexec
>> mount_option_var_tmp_nosuid
>> rpm_verify_hashes
>> sebool_httpd_can_network_connect
>> sebool_secure_mode
>> set_password_hashing_algorithm_libuserconf
>> sshd_disable_rhosts
>> sshd_enable_x11_forwarding
>> sssd_memcache_timeout
>> sssd_offline_cred_expiration
>> sssd_ssh_known_hosts_timeout
>>
>>
>> --
>> Chuck Atkins
>> Staff R Engineer, Scientific Computing
>> Kitware, Inc.
>> (518) 881-1183
>>
>> On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman > > wrote:
>>
>> On 12/12/2017 07:31 PM, Chuck Atkins wrote:
>>
>> Hi Marek,
>>
>> My apologies for the ranting tone, that was not my intent; it's
>> just been a very frustrating transition with the SSG from RHEL6
>> + STIG -> RHEL7 + OSPP since what would easily be a
>> well-documented single-command process to bring the first into
>> compliance is not so clear-cut for the second.
>>
>>  Basically - it's more about resources available, and not
>> much about
>>  our agenda. And with Ansible remediations on par with bash,
>> we
>>  should be able to fix both.
>>
>>
>> I'm all about having better, more easily maintained content.
>>So, given the current state of things, what is the right way to
>> use the SSG and it's combined ansible and bash fix content to
>> being a RHEL7 machine into compliance with the OSPP profile?
>>
>> Thanks.
>>
>> It was not intention to force (or lead) users to combine those two
>> ways, so I would suggest to stick to what is more convenient for you
>> - probably bash.
>>
>> And you can try to use newest upstream release [1]. It has more
>> stuff fixed than what was shipped in RHEL7.4. (It looks like there
>> are ~20 failing rules, and at least 3 of them left failing by
>> design, RHEL7.4 had ~30 rules failing).
>>
>> Hope it helps,
>> Marek
>>
>>
>> [1]
>> https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36
>> > >
>>
>> ___
>> scap-security-guide mailing list --
>> scap-security-guide@lists.fedorahosted.org
>> 
>> To unsubscribe send an email to
>> scap-security-guide-le...@lists.fedorahosted.org
>> 
>>
>>
>>
>>
>> ___
>> scap-security-guide mailing list -- 

Re: Ansible vs bash fixup scripts

[Marek Haicman]

Crossreferencing with my attempt to remediate basically fresh RHEL7 
installation, these are rules from your list that are in my 
OSPP-hardened system marked as failing:


audit_rules_privileged_commands
firewalld_sshd_port_enabled

So using also ansible won't help you much.


On 12/12/2017 09:35 PM, Chuck Atkins wrote:
Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following 
rules with only ansible fixes:


accounts_root_path_dirs_no_write
audit_rules_dac_modification_fchmod
audit_rules_dac_modification_fchown
audit_rules_privileged_commands
audit_rules_privileged_commands_su
audit_rules_privileged_commands_sudo
audit_rules_unsuccessful_file_modification_open
dconf_gnome_banner_enabled
dconf_gnome_disable_automount
dconf_gnome_disable_ctrlaltdel_reboot
dconf_gnome_disable_geolocation
dconf_gnome_disable_restart_shutdown
dconf_gnome_disable_thumbnailers
dconf_gnome_disable_user_admin
dconf_gnome_disable_user_list
dconf_gnome_disable_wifi_create
dconf_gnome_disable_wifi_notification
dconf_gnome_screensaver_lock_delay
dconf_gnome_screensaver_user_info
firewalld_sshd_port_enabled
gnome_gdm_disable_automatic_login
gnome_gdm_disable_guest_login
mount_option_dev_shm_nodev
mount_option_dev_shm_noexec
mount_option_dev_shm_nosuid
mount_option_home_nodev
mount_option_home_nosuid
mount_option_var_tmp_nodev
mount_option_var_tmp_noexec
mount_option_var_tmp_nosuid
rpm_verify_hashes
sebool_httpd_can_network_connect
sebool_secure_mode
set_password_hashing_algorithm_libuserconf
sshd_disable_rhosts
sshd_enable_x11_forwarding
sssd_memcache_timeout
sssd_offline_cred_expiration
sssd_ssh_known_hosts_timeout


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183

On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman > wrote:


On 12/12/2017 07:31 PM, Chuck Atkins wrote:

Hi Marek,

My apologies for the ranting tone, that was not my intent; it's
just been a very frustrating transition with the SSG from RHEL6
+ STIG -> RHEL7 + OSPP since what would easily be a
well-documented single-command process to bring the first into
compliance is not so clear-cut for the second.

     Basically - it's more about resources available, and not
much about
     our agenda. And with Ansible remediations on par with bash, we
     should be able to fix both.


I'm all about having better, more easily maintained content. 
So, given the current state of things, what is the right way to

use the SSG and it's combined ansible and bash fix content to
being a RHEL7 machine into compliance with the OSPP profile?

Thanks.

It was not intention to force (or lead) users to combine those two
ways, so I would suggest to stick to what is more convenient for you
- probably bash.

And you can try to use newest upstream release [1]. It has more
stuff fixed than what was shipped in RHEL7.4. (It looks like there
are ~20 failing rules, and at least 3 of them left failing by
design, RHEL7.4 had ~30 rules failing).

Hope it helps,
Marek


[1]
https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36


___
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org

To unsubscribe send an email to
scap-security-guide-le...@lists.fedorahosted.org





___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org


___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Chuck Atkins]

Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following
rules with only ansible fixes:

accounts_root_path_dirs_no_write
audit_rules_dac_modification_fchmod
audit_rules_dac_modification_fchown
audit_rules_privileged_commands
audit_rules_privileged_commands_su
audit_rules_privileged_commands_sudo
audit_rules_unsuccessful_file_modification_open
dconf_gnome_banner_enabled
dconf_gnome_disable_automount
dconf_gnome_disable_ctrlaltdel_reboot
dconf_gnome_disable_geolocation
dconf_gnome_disable_restart_shutdown
dconf_gnome_disable_thumbnailers
dconf_gnome_disable_user_admin
dconf_gnome_disable_user_list
dconf_gnome_disable_wifi_create
dconf_gnome_disable_wifi_notification
dconf_gnome_screensaver_lock_delay
dconf_gnome_screensaver_user_info
firewalld_sshd_port_enabled
gnome_gdm_disable_automatic_login
gnome_gdm_disable_guest_login
mount_option_dev_shm_nodev
mount_option_dev_shm_noexec
mount_option_dev_shm_nosuid
mount_option_home_nodev
mount_option_home_nosuid
mount_option_var_tmp_nodev
mount_option_var_tmp_noexec
mount_option_var_tmp_nosuid
rpm_verify_hashes
sebool_httpd_can_network_connect
sebool_secure_mode
set_password_hashing_algorithm_libuserconf
sshd_disable_rhosts
sshd_enable_x11_forwarding
sssd_memcache_timeout
sssd_offline_cred_expiration
sssd_ssh_known_hosts_timeout


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183

On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman  wrote:

> On 12/12/2017 07:31 PM, Chuck Atkins wrote:
>
>> Hi Marek,
>>
>> My apologies for the ranting tone, that was not my intent; it's just been
>> a very frustrating transition with the SSG from RHEL6 + STIG -> RHEL7 +
>> OSPP since what would easily be a well-documented single-command process to
>> bring the first into compliance is not so clear-cut for the second.
>>
>> Basically - it's more about resources available, and not much about
>> our agenda. And with Ansible remediations on par with bash, we
>> should be able to fix both.
>>
>>
>> I'm all about having better, more easily maintained content.  So, given
>> the current state of things, what is the right way to use the SSG and it's
>> combined ansible and bash fix content to being a RHEL7 machine into
>> compliance with the OSPP profile?
>>
>> Thanks.
>>
>> It was not intention to force (or lead) users to combine those two ways,
> so I would suggest to stick to what is more convenient for you - probably
> bash.
>
> And you can try to use newest upstream release [1]. It has more stuff
> fixed than what was shipped in RHEL7.4. (It looks like there are ~20
> failing rules, and at least 3 of them left failing by design, RHEL7.4 had
> ~30 rules failing).
>
> Hope it helps,
> Marek
>
>
> [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36
>
> ___
> scap-security-guide mailing list -- scap-security-gu...@lists.fedo
> rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
> s.fedorahosted.org
>
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Marek Haicman]

On 12/12/2017 07:31 PM, Chuck Atkins wrote:

Hi Marek,

My apologies for the ranting tone, that was not my intent; it's just 
been a very frustrating transition with the SSG from RHEL6 + STIG -> 
RHEL7 + OSPP since what would easily be a well-documented single-command 
process to bring the first into compliance is not so clear-cut for the 
second.


Basically - it's more about resources available, and not much about
our agenda. And with Ansible remediations on par with bash, we
should be able to fix both.


I'm all about having better, more easily maintained content.  So, given 
the current state of things, what is the right way to use the SSG and 
it's combined ansible and bash fix content to being a RHEL7 machine into 
compliance with the OSPP profile?


Thanks.

It was not intention to force (or lead) users to combine those two ways, 
so I would suggest to stick to what is more convenient for you - 
probably bash.


And you can try to use newest upstream release [1]. It has more stuff 
fixed than what was shipped in RHEL7.4. (It looks like there are ~20 
failing rules, and at least 3 of them left failing by design, RHEL7.4 
had ~30 rules failing).


Hope it helps,
Marek


[1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Matthew]

Which rules do not have bash scripts?

On Dec 12, 2017 12:24 PM, "Chuck Atkins"  wrote:

> I've got a small air-gapped network of only 2 machines that I'm setting
> up.  As such, centralized management and deployment configurations for
> larger or even moderate sized networks are really way overkill.  In the
> past with RHEL6 I could easily do it all manually, i.e. install, apply
> updates, run the STIG workstation profile with --remediate, and that would
> get me 95% of the way there.  The remainder was usually just manually
> editing a few config files and that was it.  So now that I'm trying to use
> the OSPP profile with RHEL7 I'm finding it incredibly frustrating how much
> just doesn't work out of the box now that much of the remediation content
> is in ansible only.  The mass of GDM configuration parameters can't even be
> set by "remediate" anymore because so much of the fix content is now
> ansible only.
>
> Given the mix of ansible and bash content, what's the right now to use
> this now?  Should I evaluate once and generate the ansible remediation
> playbook, apply it, then evaluate again with --remediate to apply the
> remaining bash fixes?  I've read a lot of "you can do these things with the
> ansible content now" but nothing that's really along the lines of how to
> actually generate and use it.  Earlier versions of the SSG were very easy
> to get a system up and running and almost in complete compliance with the
> government profiles, right out of the box with a single command.  The path
> to do this seems to have greatly increased in complexity, or at the very
> least, is no longer documented how to do so easily.
>
> I certainly appreciate the extra capability and content being added into
> the SSG, so I don't want this to just be a rant on diminishing that.  I do
> feel, however, that it has come at the cost of usability.
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Tue, Dec 12, 2017 at 11:52 AM, Watson Yuuma Sato 
> wrote:
>
>> Hello Chuck,
>>
>> On 12/12/17 17:35, Chuck Atkins wrote:
>>
>> There seems to be a mix of ansible and bash for fix-up scripts, in that
>> some rules only have bash fixes, others only have ansible fixes, while most
>> have both, and a few still have none.  When applying remediation during a
>> scan, which ones get used?
>>
>> When doing on-line remediation, i.e. by option "--remediate", the bash
>> fixes are applied.
>>
>> Is there a way to specify?
>>
>> Unfortunately no, the default is to use bash, and there is no way to
>> change it.
>>
>> If I have ansible installed, will the ansible fixes automatically get
>> used?  If the ansible ones are being used?  Do the bash-only fixes get run
>> as well?  What about rules that have both?
>>
>> Ansible remediations are not applied automatically, oscap can't consume
>> ansible fixes. They should be used by ansible to fix the machine.
>>
>> Oscap can only generate a script fix based on one kind of remediation, it
>> doesn't know how to use mainly one type of fix, and fill the gaps with
>> other types of remediation, but this feature sounds interesting and useful.
>>
>>
>> Thanks
>> --
>> Chuck Atkins
>> Staff R Engineer, Scientific Computing
>> Kitware, Inc.
>>
>>
>>
>> ___
>> scap-security-guide mailing list -- 
>> scap-security-guide@lists.fedorahosted.org
>> To unsubscribe send an email to 
>> scap-security-guide-le...@lists.fedorahosted.org
>>
>>
>> --
>> Watson Sato
>> Security Technologies | Red Hat, Inc
>>
>>
>> ___
>> scap-security-guide mailing list -- scap-security-gu...@lists.fedo
>> rahosted.org
>> To unsubscribe send an email to scap-security-guide-leave@list
>> s.fedorahosted.org
>>
>>
>
> ___
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org
>
>
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Chuck Atkins]

Hi Marek,

My apologies for the ranting tone, that was not my intent; it's just been a
very frustrating transition with the SSG from RHEL6 + STIG -> RHEL7 + OSPP
since what would easily be a well-documented single-command process to
bring the first into compliance is not so clear-cut for the second.

Basically - it's more about resources available, and not much about our
> agenda. And with Ansible remediations on par with bash, we should be able
> to fix both.
>

I'm all about having better, more easily maintained content.  So, given the
current state of things, what is the right way to use the SSG and it's
combined ansible and bash fix content to being a RHEL7 machine into
compliance with the OSPP profile?

Thanks.
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Marek Haicman]

Hi Chuck,
it's definitely not like we are moving away from bash remediations 
towards Ansible. As the remediation during scan is still bash-only, bash 
is still important part of SSG. It's true that in upstream SSG we tried 
to get Ansible to parity with bash, and it's even true that in some 
cases Ansible remediation is easier to make, thus is implemented first.


Basically - it's more about resources available, and not much about our 
agenda. And with Ansible remediations on par with bash, we should be 
able to fix both.


Regards,
Marek


On 12/12/2017 06:23 PM, Chuck Atkins wrote:
I've got a small air-gapped network of only 2 machines that I'm setting 
up.  As such, centralized management and deployment configurations for 
larger or even moderate sized networks are really way overkill.  In the 
past with RHEL6 I could easily do it all manually, i.e. install, apply 
updates, run the STIG workstation profile with --remediate, and that 
would get me 95% of the way there.  The remainder was usually just 
manually editing a few config files and that was it.  So now that I'm 
trying to use the OSPP profile with RHEL7 I'm finding it incredibly 
frustrating how much just doesn't work out of the box now that much of 
the remediation content is in ansible only.  The mass of GDM 
configuration parameters can't even be set by "remediate" anymore 
because so much of the fix content is now ansible only.


Given the mix of ansible and bash content, what's the right now to use 
this now?  Should I evaluate once and generate the ansible remediation 
playbook, apply it, then evaluate again with --remediate to apply the 
remaining bash fixes?  I've read a lot of "you can do these things with 
the ansible content now" but nothing that's really along the lines of 
how to actually generate and use it.  Earlier versions of the SSG were 
very easy to get a system up and running and almost in complete 
compliance with the government profiles, right out of the box with a 
single command.  The path to do this seems to have greatly increased in 
complexity, or at the very least, is no longer documented how to do so 
easily.


I certainly appreciate the extra capability and content being added into 
the SSG, so I don't want this to just be a rant on diminishing that.  I 
do feel, however, that it has come at the cost of usability.


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 11:52 AM, Watson Yuuma Sato > wrote:


Hello Chuck,

On 12/12/17 17:35, Chuck Atkins wrote:

There seems to be a mix of ansible and bash for fix-up scripts, in
that some rules only have bash fixes, others only have ansible
fixes, while most have both, and a few still have none.  When
applying remediation during a scan, which ones get used?

When doing on-line remediation, i.e. by option "--remediate", the
bash fixes are applied.

Is there a way to specify?

Unfortunately no, the default is to use bash, and there is no way to
change it.

If I have ansible installed, will the ansible fixes automatically
get used?  If the ansible ones are being used?  Do the bash-only
fixes get run as well?  What about rules that have both?

Ansible remediations are not applied automatically, oscap can't
consume ansible fixes. They should be used by ansible to fix the
machine.

Oscap can only generate a script fix based on one kind of
remediation, it doesn't know how to use mainly one type of fix, and
fill the gaps with other types of remediation, but this feature
sounds interesting and useful.



Thanks
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.



___
scap-security-guide mailing list 
--scap-security-guide@lists.fedorahosted.org

To unsubscribe send an email 
toscap-security-guide-le...@lists.fedorahosted.org




-- 
Watson Sato

Security Technologies | Red Hat, Inc


___
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org

To unsubscribe send an email to
scap-security-guide-le...@lists.fedorahosted.org





___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org


___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Chuck Atkins]

I've got a small air-gapped network of only 2 machines that I'm setting
up.  As such, centralized management and deployment configurations for
larger or even moderate sized networks are really way overkill.  In the
past with RHEL6 I could easily do it all manually, i.e. install, apply
updates, run the STIG workstation profile with --remediate, and that would
get me 95% of the way there.  The remainder was usually just manually
editing a few config files and that was it.  So now that I'm trying to use
the OSPP profile with RHEL7 I'm finding it incredibly frustrating how much
just doesn't work out of the box now that much of the remediation content
is in ansible only.  The mass of GDM configuration parameters can't even be
set by "remediate" anymore because so much of the fix content is now
ansible only.

Given the mix of ansible and bash content, what's the right now to use this
now?  Should I evaluate once and generate the ansible remediation playbook,
apply it, then evaluate again with --remediate to apply the remaining bash
fixes?  I've read a lot of "you can do these things with the ansible
content now" but nothing that's really along the lines of how to actually
generate and use it.  Earlier versions of the SSG were very easy to get a
system up and running and almost in complete compliance with the government
profiles, right out of the box with a single command.  The path to do this
seems to have greatly increased in complexity, or at the very least, is no
longer documented how to do so easily.

I certainly appreciate the extra capability and content being added into
the SSG, so I don't want this to just be a rant on diminishing that.  I do
feel, however, that it has come at the cost of usability.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 11:52 AM, Watson Yuuma Sato 
wrote:

> Hello Chuck,
>
> On 12/12/17 17:35, Chuck Atkins wrote:
>
> There seems to be a mix of ansible and bash for fix-up scripts, in that
> some rules only have bash fixes, others only have ansible fixes, while most
> have both, and a few still have none.  When applying remediation during a
> scan, which ones get used?
>
> When doing on-line remediation, i.e. by option "--remediate", the bash
> fixes are applied.
>
> Is there a way to specify?
>
> Unfortunately no, the default is to use bash, and there is no way to
> change it.
>
> If I have ansible installed, will the ansible fixes automatically get
> used?  If the ansible ones are being used?  Do the bash-only fixes get run
> as well?  What about rules that have both?
>
> Ansible remediations are not applied automatically, oscap can't consume
> ansible fixes. They should be used by ansible to fix the machine.
>
> Oscap can only generate a script fix based on one kind of remediation, it
> doesn't know how to use mainly one type of fix, and fill the gaps with
> other types of remediation, but this feature sounds interesting and useful.
>
>
> Thanks
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
>
> ___
> scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
> To unsubscribe send an email to 
> scap-security-guide-le...@lists.fedorahosted.org
>
>
> --
> Watson Sato
> Security Technologies | Red Hat, Inc
>
>
> ___
> scap-security-guide mailing list -- scap-security-gu...@lists.fedo
> rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
> s.fedorahosted.org
>
>
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Watson Yuuma Sato]

Hello Chuck,

On 12/12/17 17:35, Chuck Atkins wrote:
There seems to be a mix of ansible and bash for fix-up scripts, in 
that some rules only have bash fixes, others only have ansible fixes, 
while most have both, and a few still have none.  When applying 
remediation during a scan, which ones get used?
When doing on-line remediation, i.e. by option "--remediate", the bash 
fixes are applied.

Is there a way to specify?
Unfortunately no, the default is to use bash, and there is no way to 
change it.
If I have ansible installed, will the ansible fixes automatically get 
used?  If the ansible ones are being used?  Do the bash-only fixes get 
run as well?  What about rules that have both?
Ansible remediations are not applied automatically, oscap can't consume 
ansible fixes. They should be used by ansible to fix the machine.


Oscap can only generate a script fix based on one kind of remediation, 
it doesn't know how to use mainly one type of fix, and fill the gaps 
with other types of remediation, but this feature sounds interesting and 
useful.




Thanks
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.



___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org



--
Watson Sato
Security Technologies | Red Hat, Inc

___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Ansible vs bash fixup scripts

[Chuck Atkins]

There seems to be a mix of ansible and bash for fix-up scripts, in that
some rules only have bash fixes, others only have ansible fixes, while most
have both, and a few still have none.  When applying remediation during a
scan, which ones get used?  Is there a way to specify?  If I have ansible
installed, will the ansible fixes automatically get used?  If the ansible
ones are being used?  Do the bash-only fixes get run as well?  What about
rules that have both?

Thanks
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org