5:14 p.m.
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.pellitt(a)navy.mil
________________________________
From: Chuck Atkins [chuck.atkins(a)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&D Engineer, Scientific Computing
Kitware, Inc.
On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman
<mhaicman@redhat.com<mailto: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<tel:%28518%29%20881-1183>
On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman
<mhaicman@redhat.com<mailto:mhaicman@redhat.com>
<mailto: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>
<mailto: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>
<mailto: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<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<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>
10:30 p.m.
New subject: Ansible vs bash fixup scripts
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.pellitt(a)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.pellitt(a)navy.mil
________________________________
From: Chuck Atkins [chuck.atkins(a)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&D Engineer, Scientific Computing
Kitware, Inc.
On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman <mhaicman(a)redhat.com
<mailto: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<tel:%28518%29%20881-1183>
On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman <mhaicman(a)redhat.com
<mailto:mhaicman@redhat.com> <mailto:mhaicman@redhat.com<mailto:
mhaicman(a)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(a)lists.fedorahosted.org>
<mailto:scap-security-guide@lists.fedorahosted.org<mailto:
scap-security-guide(a)lists.fedorahosted.org>>
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org<mailto:
scap-security-guide-leave(a)lists.fedorahosted.org>
<mailto:scap-security-guide-leave@lists.fedorahosted.org<mailto:
scap-security-guide-leave(a)lists.fedorahosted.org>>
_______________________________________________
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<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
1:35 a.m.
New subject: EXTERNAL: Re: Ansible vs bash fixup scripts
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
<simontek@gmail.com<mailto:simontek@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.pellitt@navy.mil<mailto:chad.pellitt@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.pellitt@navy.mil<mailto:chad.pellitt@navy.mil>
________________________________
From: Chuck Atkins [chuck.atkins@kitware.com<mailto:chuck.atkins@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&D Engineer, Scientific Computing
Kitware, Inc.
On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman
<mhaicman@redhat.com<mailto:mhaicman@redhat.com><mailto:mhaicman@redhat.com<mailto: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<tel:%28518%29%20881-1183><tel:%28518%29%20881-1183>
On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman
<mhaicman@redhat.com<mailto:mhaicman@redhat.com><mailto:mhaicman@redhat.com<mailto:mhaicman@redhat.com>>
<mailto:mhaicman@redhat.com<mailto:mhaicman@redhat.com><mailto: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><mailto:scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>>
<mailto:scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org><mailto: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><mailto:scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>>
<mailto:scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org><mailto: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<mailto:scap-security-guide@lists.fedorahosted.org><mailto: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><mailto: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<mailto:scap-security-guide@lists.fedorahosted.org><mailto: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><mailto: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<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<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>
2318
days inactive
2321
days old
scap-security-guide@lists.fedorahosted.org
2 comments
3 participants
participants (3)
-
Albrecht, Thomas C -
Matthew -
Pellitt, Chad CIV CDSA Dam Neck, R21