scap-security-guide March 2014

scap-security-guide@lists.fedorahosted.org

23 participants
41 discussions

NIST 800-53 identifiers
by Kordell, Luke T 30 Aug '14

30 Aug '14

Hello, I noticed that the majority of the rule definitions now have NIST 800-53 identifiers or an empty set of quotes where an identifier will be added. Is there a way to get the already-added identifiers to show-up on the .html scan results? At the moment all I can see is the CCE number. Thanks, Luke K

5 6

[PATCH] [shared] sshd_set_idle_timeout - when doing the check be sure to check also the lower bound of ClientAliveInterval value.
by Jan Lieskovsky 20 May '14

20 May '14

This improvement was originally proposed by Tomas Heinrich for USGCB content. But it is applicable to SSG content too, therefore this post. Rationale: ---------- When checking the system for underlying value of ClientAliveInterval sshd config variable it's not sufficient to check just for upper bound (if the present value is less than required maximum), but it is necessary to check also for lower bound. Because from the sshd_config manual page: ClientAliveInterval Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. This option applies to protocol version 2 only. Conclusion: ----------- The current form worked only for instances, not having ClientAliveInterval at all in the config. But having had that value set to zero, would still pass (which is wrong, since as mentioned above these messages would still not be sent). Thus this patch adds also check if actual value is greater than zero. Besides that it add some blank lines for better readability. Also removes Fedora version of sshd_set_idle_timeout.xml rule and links to shared one. Testing background: ------------------- Has been tested on RHEL-7 & Fedora-20 and seems to be working properly. Please review. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

7 15

Problem with Setting faillock Account Lock Time
by Spice, Adam M CTR USARMY ARL (US) 14 May '14

14 May '14

All, My systems failed the scans for CCE-26844-1 (Set Deny For Failed Password Attempts), CCE-27110-6 (Set Lockout Time For Failed Password Attempts) and CCE-27215-3 (Set Interval For Counting Failed Password Attempts). I was able to resolve the first and last by following the fix text, but CCE-27110-6 remains a problem. The fix text instructs me to add the following lines: auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900 auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900 ... directly beneath the following line in /etc/pam.d/system-auth: auth required pam_env.so However, following these instructions results in a system whose GDM prompts me for a username, but never gets to the password. The logs show "gkr-pam: no password is available for user." I performed many Google searches, not really finding much that helped me other than an old message in this group: https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-February/0 02601.html Unfortunately, I didn't see a resolution. The person who started that thread opened a ticket, but it doesn't look like it was addressed: https://fedorahosted.org/scap-security-guide/ticket/255 He also referenced a Red Hat Solution that provides instructions on enabling faillock; following this, I was able to restore my system to functionality. I could login; if I failed my attempt three times, I could no longer login; pam_tally2 no longer reported failed logins, but faillock did. I haven't yet spent the week to determine whether or not the unlock_time parameter is being applied (if you know of a way to report remaining time until an account unlocks, that would help). Is there any guidance available regarding passing this scan without disabling my system? Thank you! -- Adam Spice Contractor, STG Unix support, Army Research Labs

4 6

[PATCH] Service cgred (service name for binary cgrulesengd) is gone in RHEL 7.
by Maura Dailey 12 May '14

12 May '14

I noticed that cgred.service was not present in libcgroup-tools in the RHEL 7 beta. cgred.service is the service file that controls the daemon cgrulesengd. # rpm -q --changelog libcgroup-tools * Mon Nov 04 2013 Peter Schiffer <pschiffe(a)redhat.com> 0.40-0.rc1.3 - related: #819568 fixed some coverity findings * Fri Nov 01 2013 Peter Schiffer <pschiffe(a)redhat.com> 0.40-0.rc1.2 - related: #1016810 returned creation of cgred group, which was removed in previous commit by mistage * Fri Nov 01 2013 Peter Schiffer <pschiffe(a)redhat.com> 0.40-0.rc1.1 - resolves: #819568, #740113 rebased to 0.40.rc1 - resolves: #983264 rebuilt with full relro and PIE - resolves: #1016810 removed cgrulesengd daemon ... Please note that in the last line displayed here, cgrulesengd is listed as having been removed. RHEL Bugzilla reference here (I can't read the actual bug from the changelog, but there's a link to it on this page): https://bugzilla.redhat.com/show_bug.cgi?id=1034248 - Maura Dailey Signed-off-by: Maura Dailey <maura(a)eclipse.ncsc.mil> --- RHEL/7/input/fixes/bash/service_cgred_disabled.sh | 9 --------- RHEL/7/input/services/base.xml | 15 --------------- 2 files changed, 0 insertions(+), 24 deletions(-) delete mode 100644 RHEL/7/input/fixes/bash/service_cgred_disabled.sh diff --git a/RHEL/7/input/fixes/bash/service_cgred_disabled.sh b/RHEL/7/input/fixes/bash/service_cgred_disabled.sh deleted file mode 100644 index e4d7301..0000000 --- a/RHEL/7/input/fixes/bash/service_cgred_disabled.sh +++ /dev/null @@ -1,9 +0,0 @@ -# -# Disable cgred for all run levels -# -chkconfig --level 0123456 cgred off - -# -# Stop cgred if currently running -# -service cgred stop diff --git a/RHEL/7/input/services/base.xml b/RHEL/7/input/services/base.xml index 4f2c05a..5c0941c 100644 --- a/RHEL/7/input/services/base.xml +++ b/RHEL/7/input/services/base.xml @@ -75,21 +75,6 @@ service is not necessary. <ref nist="CM-7" /> </Rule> -<Rule id="service_cgred_disabled"> -<title>Disable Control Group Rules Engine (cgred)</title> -<description>The <tt>cgred</tt> service moves tasks into control groups according to -parameters set in the <tt>/etc/cgrules.conf</tt> configuration file. -<service-disable-macro service="cgred" /> -</description> -<ocil><service-disable-check-macro service="cgred" /></ocil> -<rationale>Unless control groups are used to manage system resources, running the cgred service -service is not necessary. -</rationale> -<ident cce="RHEL7-CCE-TBD" /> -<oval id="service_cgred_disabled" /> -<ref nist="CM-7" /> -</Rule> - <Rule id="service_cpuspeed_disabled"> <title>Disable CPU Speed (cpuspeed)</title> <description>The <tt>cpuspeed</tt> service can adjust the clock speed of supported CPUs based upon -- 1.7.1

4 6

FW: [PATCH] New Rule for RHEL-06-000029 -- Lock non-root system accounts
by Steinke, Leland J Sr CTR DISA DD (US) 25 Apr '14

25 Apr '14

The updates validated with OSCAP, but the verify-references.py script spat it up. It looks good to me, otherwise. Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr(a)mail.mil (gov't) lsteinke(a)tapestrytech.com (com'l)

4 9

Rule ensure_redhat_gpgkey_installed
by Steinke, Leland J Sr CTR DISA DD (US) 25 Apr '14

25 Apr '14

The OVAL check for the Red Hat release and auxiliary key packages is passing when the packages are not installed. The check_existence and check attributes on the associated rpminfo_test elements are set to "any_exist" and "only one", respectively. Shouldn't the check_existence attribute be "at_least_one_exists" for these tests instead? Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr(a)mail.mil (gov't) lsteinke(a)tapestrytech.com (com'l)

2 1

[PATCH] correct several STIG/SSG mappings
by Steinke, Leland J Sr CTR DISA DD (US) 25 Apr '14

25 Apr '14

These are corrections to several mappings in stig_overlay.xml. Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr(a)mail.mil (gov't) lsteinke(a)tapestrytech.com (com'l) --- RHEL6/input/auxiliary/stig_overlay.xml | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/RHEL6/input/auxiliary/stig_overlay.xml b/RHEL6/input/auxiliary/stig_overlay.xml index 9b613eb..8e89373 100644 --- a/RHEL6/input/auxiliary/stig_overlay.xml +++ b/RHEL6/input/auxiliary/stig_overlay.xml @@ -66,7 +66,7 @@ <overlay owner="disastig" ruleid="no_hashes_outside_shadow" ownerid="RHEL-06-000031" disa="366" severity="medium"> <title>The /etc/passwd file must not contain password hashes.</title> </overlay> - <overlay owner="disastig" ruleid="no_uidzero_except_root" ownerid="RHEL-06-000032" disa="366" severity="medium"> + <overlay owner="disastig" ruleid="accounts_no_uid_except_zero" ownerid="RHEL-06-000032" disa="366" severity="medium"> <title>The root account must be the only account having a UID of 0.</title> </overlay> <overlay owner="disastig" ruleid="userowner_shadow_file" ownerid="RHEL-06-000033" disa="366" severity="medium"> @@ -234,7 +234,7 @@ <overlay owner="disastig" ruleid="kernel_module_ipv6_option_disabled" ownerid="RHEL-06-000098" disa="366" severity="medium"> <title>The IPv6 protocol handler must not be bound to the network stack unless needed.</title> </overlay> - <overlay owner="disastig" ruleid="sysctl_net_ipv6_conf_default_accept_redirects_value" ownerid="RHEL-06-000099" disa="366" severity="medium"> + <overlay owner="disastig" ruleid="sysctl_ipv6_default_accept_redirects" ownerid="RHEL-06-000099" disa="366" severity="medium"> <title>The system must ignore ICMPv6 redirects by default.</title> </overlay> <overlay owner="disastig" ruleid="service_ip6tables_enabled" ownerid="RHEL-06-000103" disa="1118" severity="medium"> @@ -351,7 +351,7 @@ <overlay owner="disastig" ruleid="configure_auditd_max_log_file_action" ownerid="RHEL-06-000161" disa="366" severity="medium"> <title>The system must rotate audit log files that reach the maximum file size.</title> </overlay> - <overlay owner="disastig" ruleid="configure_auditd_admin_space_left_action" ownerid="RHEL-06-000163" disa="1343" severity="medium"> + <overlay owner="disastig" ruleid="nonselected" ownerid="RHEL-06-000163" disa="1343" severity="medium"> <title>The audit system must switch the system to single-user mode when available audit storage volume becomes dangerously low.</title> </overlay> <overlay owner="disastig" ruleid="audit_rules_time_adjtimex" ownerid="RHEL-06-000165" disa="169" severity="low"> @@ -747,16 +747,16 @@ <overlay owner="disastig" ruleid="snmpd_not_default_password" ownerid="RHEL-06-000341" disa="366" severity="high"> <title>The snmpd service must not use a default password.</title> </overlay> - <overlay owner="disastig" ruleid="user_umask_bashrc" ownerid="RHEL-06-000342" disa="366" severity="low"> + <overlay owner="disastig" ruleid="accounts_umask_bashrc" ownerid="RHEL-06-000342" disa="366" severity="low"> <title>The system default umask for the bash shell must be 077.</title> </overlay> - <overlay owner="disastig" ruleid="user_umask_cshrc" ownerid="RHEL-06-000343" disa="366" severity="low"> + <overlay owner="disastig" ruleid="accounts_umask_cshrc" ownerid="RHEL-06-000343" disa="366" severity="low"> <title>The system default umask for the csh shell must be 077.</title> </overlay> - <overlay owner="disastig" ruleid="user_umask_profile" ownerid="RHEL-06-000344" disa="366" severity="low"> + <overlay owner="disastig" ruleid="accounts_umask_etc_profile" ownerid="RHEL-06-000344" disa="366" severity="low"> <title>The system default umask in /etc/profile must be 077.</title> </overlay> - <overlay owner="disastig" ruleid="user_umask_logindefs" ownerid="RHEL-06-000345" disa="366" severity="low"> + <overlay owner="disastig" ruleid="accounts_umask_login_defs" ownerid="RHEL-06-000345" disa="366" severity="low"> <title>The system default umask in /etc/login.defs must be 077.</title> </overlay> <overlay owner="disastig" ruleid="umask_for_daemons" ownerid="RHEL-06-000346" disa="366" severity="low"> -- 1.7.1

3 6

[PATCH] update disable_user_list check and fix and add OVAL
by Steinke, Leland J Sr CTR DISA DD (US) 25 Apr '14

25 Apr '14

This patch includes OVAL for the disable_user_list Rule. It also updates the check and fix to look at the same thing. Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr(a)mail.mil (gov't) lsteinke(a)tapestrytech.com (com'l)

2 2

[RFC] time to move to github?
by Shawn Wells 09 Apr '14

09 Apr '14

As the SSG development community grows, so does the need for matured tools and workflow. There's been some discussion of moving to GitHub. On the pro side: * Easier to signup and request commit access * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * Dramatically better ticketing system - labels - user-friendly GUI - git commit hooks (put ticket # in patch title, auto resolves ticket) - multi-developer collaboration on tickets easier through @name calls * "Pull Request" concept: Patches centrally managed and merged, ensures no missed patches on mailing list * Simplified branching (e.g. allows a -stable and -dev branch). Possible on FedoraHosted, not as intuitive * Increased reliability of infrastructure (especially latency of git pulls) On the cons: * Slight developer hassle to migrate SSH keys * "Not hosted by RedHat" -- concern from some that migrating from a redhat/fedora hosted URL will diminish project brand. What does everyone think?

19 55

MLS_CSCF profile
by Kordell, Luke T 03 Apr '14

03 Apr '14

Here is a profile I have been developing. Some of the rules within the profile contradict each other, but the future plan is to break-up this profile into a few different releases. We will eventually have an HPC, Cluster, US and generic version of this profile each with slightly different rule selections. The selinux ploicy rule will always be refined to check that selinux is implementing the mls policy type. Let me know if you have any questions or suggestions! Luke K

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide March 2014