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 <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&D Engineer, Scientific Computing
>> Kitware, Inc.
>> (518) 881-1183
>>
>> On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman <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).
>>
>>     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-le...@lists.fedorahosted.org
>>     <mailto:scap-security-guide-le...@lists.fedorahosted.org>
>>
>>
>>
>>
>> _______________________________________________
>> 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-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

Reply via email to