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&D Engineer, Scientific Computing Kitware, Inc.
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&D 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-leave@lists.fedorahosted.org
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&D Engineer, Scientific Computing Kitware, Inc.
On Tue, Dec 12, 2017 at 11:52 AM, Watson Yuuma Sato wsato@redhat.com 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&D 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-leave@lists.fedorahosted.org
-- Watson Sato Security Technologies | Red Hat, Inc
scap-security-guide mailing list -- scap-security-guide@lists.fedo rahosted.org To unsubscribe send an email to scap-security-guide-leave@list s.fedorahosted.org
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&D Engineer, Scientific Computing Kitware, Inc.
On Tue, Dec 12, 2017 at 11:52 AM, Watson Yuuma Sato <wsato@redhat.com mailto:wsato@redhat.com> 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&D Engineer, Scientific Computing Kitware, Inc. _______________________________________________ scap-security-guide mailing list --scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email toscap-security-guide-leave@lists.fedorahosted.org <mailto:scap-security-guide-leave@lists.fedorahosted.org>-- Watson Sato Security Technologies | Red Hat, Inc _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org <mailto: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-leave@lists.fedorahosted.org
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.
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
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&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman mhaicman@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).
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.fedo rahosted.org To unsubscribe send an email to scap-security-guide-leave@list s.fedorahosted.org
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&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman <mhaicman@redhat.com mailto:mhaicman@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). Hope it helps, Marek [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36 <https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36> _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org <mailto: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-leave@lists.fedorahosted.org
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&D Engineer, Scientific Computing Kitware, Inc.
On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman mhaicman@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&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman <mhaicman@redhat.com mailto:mhaicman@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). Hope it helps, Marek [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36 <https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org <mailto:scap-security-guide-leave@lists.fedorahosted.org>
scap-security-guide mailing list -- scap-security-guide@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.fedo rahosted.org To unsubscribe send an email to scap-security-guide-leave@list s.fedorahosted.org
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.atkins@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&D Engineer, Scientific Computing Kitware, Inc.
On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman mhaicman@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&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman <mhaicman@redhat.com mailto:mhaicman@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). Hope it helps, Marek [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36 <https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36>
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org <mailto:scap-security-guide-leave@lists.fedorahosted.org>
scap-security-guide mailing list -- scap-security-guide@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.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
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
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
Which rules do not have bash scripts?
On Dec 12, 2017 12:24 PM, "Chuck Atkins" chuck.atkins@kitware.com 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&D Engineer, Scientific Computing Kitware, Inc.
On Tue, Dec 12, 2017 at 11:52 AM, Watson Yuuma Sato wsato@redhat.com 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&D 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-leave@lists.fedorahosted.org
-- Watson Sato Security Technologies | Red Hat, Inc
scap-security-guide mailing list -- scap-security-guide@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@lists.fedorahosted.org
-
Chuck Atkins -
Gabe Alford -
Marek Haicman -
Matthew -
Olivier BONHOMME -
Watson Yuuma Sato