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" < [email protected]> 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 > [email protected] > ________________________________ > From: Chuck Atkins [[email protected]] > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> <mailto:[email protected]<mailto: > [email protected]>>> 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 -- > [email protected]<mailto:scap- > [email protected]> > <mailto:[email protected]<mailto: > [email protected]>> > To unsubscribe send an email to > [email protected]<mailto: > [email protected]> > <mailto:[email protected]<mailto: > [email protected]>> > > > > > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide@lists. > fedorahosted.org<mailto:[email protected]> > 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:[email protected]> > 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 >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
