Thanks. I hope you are able to get the scripts included into the SSG. I didn't know how to do github contributions until it was posted earlier in this thread.
David Paige, CISSP USAICoE CIO/G6, Contractor Sr. Systems Engineer II 520-533-6213 david.b.paige....@mail.mil -----Original Message----- From: Pellitt, Chad CIV CDSA Dam Neck, R21 [mailto:chad.pell...@navy.mil] Sent: Friday, December 15, 2017 10:05 AM To: SCAP Security Guide <scap-security-guide@lists.fedorahosted.org> Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ---- The scripts have been uploaded here: Caution-https://github.com/OpenSCAP/scap-security-guide/issues/2494 Chad Pellitt CDSA Dam Neck R21 chad.pell...@navy.mil ________________________________________ From: Marek Haicman [mhaic...@redhat.com] Sent: Friday, December 15, 2017 4:59 AM To: scap-security-guide@lists.fedorahosted.org 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 Caution-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 > chad.pell...@navy.mil > ________________________________ > From: Gabe Alford [redhatri...@gmail.com] > 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 > <chuck.atk...@kitware.com<Caution-mailto:chuck.atk...@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 > <mhaic...@redhat.com<Caution-mailto: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<tel:%28518%29%20881-1183> > > On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman > <mhaic...@redhat.com<Caution-mailto:mhaic...@redhat.com> > <Caution-mailto:mhaic...@redhat.com<Caution-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] > > Caution-https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36 > > <Caution-https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.36> > > _______________________________________________ > scap-security-guide mailing list -- > > scap-security-guide@lists.fedorahosted.org<Caution-mailto:scap-security-guide@lists.fedorahosted.org> > > <Caution-mailto:scap-security-guide@lists.fedorahosted.org<Caution-mailto:scap-security-guide@lists.fedorahosted.org>> > To unsubscribe send an email to > > scap-security-guide-le...@lists.fedorahosted.org<Caution-mailto:scap-security-guide-le...@lists.fedorahosted.org> > > <Caution-mailto:scap-security-guide-le...@lists.fedorahosted.org<Caution-mailto:scap-security-guide-le...@lists.fedorahosted.org>> > > > > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide@lists.fedorahosted.org<Caution-mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to > scap-security-guide-le...@lists.fedorahosted.org<Caution-mailto:scap-security-guide-le...@lists.fedorahosted.org> > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide@lists.fedorahosted.org<Caution-mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to > scap-security-guide-le...@lists.fedorahosted.org<Caution-mailto:scap-security-guide-le...@lists.fedorahosted.org> > > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide@lists.fedorahosted.org<Caution-mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to > scap-security-guide-le...@lists.fedorahosted.org<Caution-mailto:scap-security-guide-le...@lists.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 > _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.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 _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
