December 2017 - scap-security-guide

by Trevor Vaughan

Hi All, I've been re-roaming through the SSG and this is probably the first of a many part thread regarding different checks. TL;DR; The potential risk caused by enabling 'repo_gpgcheck' outweighs any potential benefit if TLS is enabled. In my opinion, the following check should *only* be enabled if all of your repositories are internally managed xccdf_org.ssgproject.content_rule_ensure_gpgcheck_repo_metadata. The reason for this is that YUM presently does not (to my knowledge) have any way to differentiate between package signing GPG keys and repo signing GPG keys. This means that if, for instance, I host my packages via some shared Nexus, then I have to add the Nexus GPG key to my trust list for the repo. I fundamentally do *not* want to do this! I shouldn't be allowing my Nexus maintainer to potentially install software on my system without my explicit knowledge. You should use TLS, and the repo should have a trusted certificate there and that should be sufficient for the metadata until RPM can tell the difference between these two certificates. Please let me know if I've missed something, but I don't remember seeing options to split out the two sets of certs. Additionally, this is marked as 'high' severity and that seems to be massive overkill considering that 1) the packages are still signed and validated and 2) TLS is required. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

5 years, 5 months

7
20
0 / 0

Ansible vs bash fixup scripts

by Chuck Atkins

There seems to be a mix of ansible and bash for fix-up scripts, in that some rules only have bash fixes, others only have ansible fixes, while most have both, and a few still have none. When applying remediation during a scan, which ones get used? Is there a way to specify? If I have ansible installed, will the ansible fixes automatically get used? If the ansible ones are being used? Do the bash-only fixes get run as well? What about rules that have both? Thanks ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc.

6 years, 3 months

6
12
0 / 0

Issues for writing a remediation

by Olivier BONHOMME

Hello everybody, I'm trying to write my first OVAL check and the associated remediation script. For my first try, I decided to test with a simple check https://github.com/OpenSCAP/scap-security-guide/issues/1861. I think, I succedeed writing the OVAL check but I have big issues with the remediation : When I execute the remediate command using the results file from the eval command, my remediation is never selected. After some investigations, I realized that the fix wasn't generated into the results file. I must admit I'm a little bit lost and I don't understand why my remediation fix is not generated into the results file. That's why i'm looking for some help in order to understand how to investigate for resolving that issue (Which i'm sure is a newbie thing) I put my files on the following GIST : https://gist.github.com/ptitoliv/fe10d4d37049801b60c98b255c7a6d66 Thanks for your help. Regards, Olivier Bonhomme

6 years, 3 months

4
6
0 / 0

open-scap.org expired cert

by Tom Albrecht

All, Looks like the TLS cert expired on https://www.open-scap.org a couple days ago. Need to check the letsencrypt cron job. Tom A.

6 years, 3 months

3
2
0 / 0

Re: Ansible vs bash fixup scripts

by Pellitt, Chad CIV CDSA Dam Neck, R21

The scripts have been uploaded here: https://github.com/OpenSCAP/scap-security-guide/issues/2494 Chad Pellitt CDSA Dam Neck R21 chad.pellitt(a)navy.mil ________________________________________ From: Marek Haicman [mhaicman(a)redhat.com] Sent: Friday, December 15, 2017 4:59 AM To: scap-security-guide(a)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 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.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@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/tag/v0.1.36> > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> > <mailto:scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> > <mailto:scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>> > > > > > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> > > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> > > > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> > > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org > _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org

6 years, 4 months

2
1
0 / 0

Re: Ansible vs bash fixup scripts

by Pellitt, Chad CIV CDSA Dam Neck, R21

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@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/tag/v0.1.36> _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> <mailto:scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> <mailto:scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>> _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>

6 years, 4 months

3
2
0 / 0

Re: Ansible vs bash fixup scripts

by Pellitt, Chad CIV CDSA Dam Neck, R21

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 chad.pellitt(a)navy.mil ________________________________ From: Chuck Atkins [chuck.atkins(a)kitware.com] 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 <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@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/tag/v0.1.36> _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> <mailto:scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> <mailto:scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>> _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>

6 years, 4 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide December 2017