That's all we have to do to submit code? I would've done that ages ago. On Dec 15, 2017 4:59 AM, "Marek Haicman" <[email protected]> wrote:
> 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/sc > ap-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/t >> ag/v0.1.36> >> >> _______________________________________________ >> scap-security-guide mailing list -- >> [email protected]<mailto:scap-secu >> [email protected]> >> <mailto:[email protected]<mailto:s >> [email protected]>> >> To unsubscribe send an email to >> [email protected]<mailto:sca >> [email protected]> >> <mailto:[email protected]<mailto: >> [email protected]>> >> >> >> >> >> _______________________________________________ >> scap-security-guide mailing list -- [email protected] >> rahosted.org<mailto:[email protected]> >> To unsubscribe send an email to scap-security-guide-leave@list >> s.fedorahosted.org<mailto:scap-security-guide-leave@lists. >> fedorahosted.org> >> >> _______________________________________________ >> scap-security-guide mailing list -- [email protected] >> rahosted.org<mailto:[email protected]> >> To unsubscribe send an email to scap-security-guide-leave@list >> s.fedorahosted.org<mailto:scap-security-guide-leave@lists. >> fedorahosted.org> >> >> >> _______________________________________________ >> scap-security-guide mailing list -- [email protected] >> rahosted.org<mailto:[email protected]> >> To unsubscribe send an email to scap-security-guide-leave@list >> s.fedorahosted.org<mailto:scap-security-guide-leave@lists. >> fedorahosted.org> >> >> _______________________________________________ >> scap-security-guide mailing list -- [email protected] >> rahosted.org >> To unsubscribe send an email to scap-security-guide-leave@list >> s.fedorahosted.org >> >> _______________________________________________ > scap-security-guide mailing list -- [email protected] > rahosted.org > To unsubscribe send an email to scap-security-guide-leave@list > s.fedorahosted.org >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
