The scripts have been uploaded here: https://github.com/OpenSCAP/scap-security-guide/issues/2494
Chad Pellitt CDSA Dam Neck R21 [email protected] ________________________________________ From: Marek Haicman [[email protected]] Sent: Friday, December 15, 2017 4:59 AM To: [email protected] 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 > [email protected] > ________________________________ > From: Gabe Alford [[email protected]] > 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 > <[email protected]<mailto:[email protected]>> 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 > <[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:[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 -- > [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> > > _______________________________________________ > scap-security-guide mailing list -- > [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> > > > _______________________________________________ > scap-security-guide mailing list -- > [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> > > _______________________________________________ > scap-security-guide mailing list -- [email protected] > To unsubscribe send an email to > [email protected] > _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
