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" <mhaicman(a)redhat.com> 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
> chad.pellitt(a)navy.mil
> ________________________________
> From: Gabe Alford [redhatrises(a)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.atkins(a)kitware.com
> <mailto:chuck.atkins@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 <mhaicman(a)redhat.com
> <mailto:mhaicman@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 <mhaicman(a)redhat.com
> <mailto:mhaicman@redhat.com> <mailto:mhaicman@redhat.com<mailto:
> mhaicman(a)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/t
> ag/v0.1.36>
>
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide@lists.fedorahosted.org<mailto:scap-secu
> rity-guide(a)lists.fedorahosted.org>
> <mailto:scap-security-guide@lists.fedorahosted.org<mailto:s
> cap-security-guide(a)lists.fedorahosted.org>>
> To unsubscribe send an email to
> scap-security-guide-leave@lists.fedorahosted.org<mailto:sca
> p-security-guide-leave(a)lists.fedorahosted.org>
> <mailto:scap-security-guide-leave@lists.fedorahosted.org<mailto:
> scap-security-guide-leave(a)lists.fedorahosted.org>>
>
>
>
>
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
> rahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
> 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 -- scap-security-guide(a)lists.fedo
> rahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
> 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 -- scap-security-guide(a)lists.fedo
> rahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
> 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 -- scap-security-guide(a)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(a)lists.fedo
rahosted.org
To unsubscribe send an email to scap-security-guide-leave@list
s.fedorahosted.org