scap-security-guide October 2014

scap-security-guide@lists.fedorahosted.org

16 participants
17 discussions

2015 Red Hat Summit: Discounted passes for SSG & OpenSCAP community members
by Shawn Wells 25 Mar '15

25 Mar '15

Hey Guys, The 2015 Red Hat Summit (http://www.redhat.com/summit) will take place June 23-26 in Boston. The event may seem far away, but we all know how long it takes for integrators and govies to allocate training and travel budgets... :) This year we've ensured that _*any*_ member of the SSG & broader OpenSCAP community is eligible for discounted Summit passes at $950/pass (or $895/pass for groups of 4+). Doesn't matter if you're a code contributor, occasional voice on the mailing lists, or silent partner. For reference, the full conference pass is generally $1,975 (ref http://www.redhat.com/summit/rates/). In 2012 the SCAP session was standing room only, and in 2013 it was rated the #3 session (out of 196 sessions) by attendees. We hope to see you there this year! In full transparency: I don't get any RHT kickback or commissions off this. I received a special registration code that allows me to empirically show various managers/event staff how much interest there is in SCAP and Security Automation. For every 10 registrants that use the code, I get to send a RHT engineer to Red Hat Summit. Contact me _*off-list*_ if interested! -sdw

2 2

sshd banner warning
by Jeremiah Jahn 21 Jan '15

21 Jan '15

We used to have to keep out banners under /etc/issue for the console, and /etc/issue.net for remote access. Would it be okay to make this rule deal with either one? diff --git a/shared/oval/sshd_enable_warning_banner.xml b/shared/oval/sshd_enable_warning_banner.xml index 0bd8d32..ace8b75 100644 --- a/shared/oval/sshd_enable_warning_banner.xml +++ b/shared/oval/sshd_enable_warning_banner.xml @@ -25,7 +25,7 @@ </ind:textfilecontent54_test> <ind:textfilecontent54_object id="obj_sshd_banner_set" version="2"> <ind:filepath>/etc/ssh/sshd_config</ind:filepath> - <ind:pattern operation="pattern match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue[\s]*(?:|(?:#.*))?$</ind:pattern> + <ind:pattern operation="pattern match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue(.net){0,1}[\s]*(?:|(?:#.*))?$</ind:pattern> <ind:instance datatype="int">1</ind:instance> </ind:textfilecontent54_object> </def-group>

5 9

Configuration testing vs Forensic testing
by Steve Grubb 07 Jan '15

07 Jan '15

Hello, I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed. Some examples to illustrate the point: Forensic Configuration ----------------------------------------------------------------- auditctl -l vs cat /etc/audit/audit.rules mount vs cat /etc/fstab sysctl -a vs cat/etc/sysctl.conf service ip6tables status vs chkconfig ip6tables --list All these need to be changed in the prose to better express what the SCAP tool is actually checking. IOW, you can get different results by hand than the tool itself would report. This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline. Thanks, -Steve

5 15

Use of RHEV
by Gabe Alford 21 Nov '14

21 Nov '14

Hello list, I wanted to ask if anyone is using RHEV at all especially in an IC/DoD environment. Has it been approved? Secured? What issues are there? Thanks, Gabe

6 12

Celebrating 20 years of Red Hat Linux
by Shawn Wells 01 Nov '14

01 Nov '14

Today Red Hatters around the world are celebrating the twentieth anniversary of the first release of Red Hat Linux, the Halloween release, that set the stage for what has become RHEL: http://red.ht/1tl2KYN Wanted to say thank you to everyone in the community who has participated in the OpenSCAP and SSG communities. Between the OpenSCAP interpreter and SSG projects there has been ~100 individuals contribute code across 8,113 patches and 1,639,072 lines of code [1][2]. OpenSCAP established itself as the only open source, NIST certified interpreter. The SSG project worked with government agencies, such as DISA FSO, NSA, and NRO, to not only release their baselines, but incorporate them into an open source project. RHEL now natively includes these tools and content to natively support security baseline attestation and continuous monitoring. It's been an amazing ride. Back in 1998 I rode my /bicycle/ to purchase Red Hat Linux 5.2 (I was in 5th grade!), as my Windows desktop crapped out. I didn't actually know what Linux was. All I knew was that I needed an operating system, and that the Red Hat box had a cheaper sticker price than the Microsoft one. After installing RHL I began exploring the Linux community, becoming fascinated by it. The open source model fascinated me. As a kid I imagined how amazing it'd be to someday work with the brightest minds possible, to create technology that would be used all over the world, to help make things better on a massive scale. Working with the OpenSCAP and SSG communities has fulfilled that personal dream. I can't imagine collaborating with a better group of people. Sincerely, on behalf of Red Hat, and on behalf of myself, thank you to everyone who has participated in the communities. Everyone here has touched technology that now ships in Linux. Take a second to reflect on that -- it's an amazing accomplishment! -Shawn [1] http://people.redhat.com/swells/gitstats/20141031-scap-security-guide/activ… [2] http://people.redhat.com/swells/gitstats/20141031-openscap/activity.html -- Shawn Wells Director, Innovation Programs shawn(a)redhat.com | 443.534.0130 @shawndwells

2 3

Introducing project SCAPtimony
by Šimon Lukašík 30 Oct '14

30 Oct '14

Hey! Here are few words about new SCAP project we have started couple weeks ago: http://isimluk.livejournal.com/4908.html The project is at its early stage, but I welcome all the comments and suggestions. I hope you'll enjoy the read. -- Simon Lukasik Security Technologies, Red Hat, Inc. https://github.com/isimluk

1 0

Re: [gov-sec] The output of auditctl has changed in RHEL 6.6
by Shawn Wells 28 Oct '14

28 Oct '14

On 10/27/14, 9:32 AM, Steve Grubb wrote: > Hello, > > On Friday, October 24, 2014 11:48:57 AM Glass, Jermaine CTR/NSOC wrote: >> Although a new STIG was released today, I didn't see where that new STIG >> took the below information in consideration. > First, Red Hat Security Engineering has not reviewed the RHEL 6 STIG. Well, not only has it been reviewed by Red Hat, it's shipping in RHEL 6.6: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/ht… This reflects over three years of work by engineering staff, and is a *huge* accomplishment to those involved! ~55% was written by Red Hat staff, ~38% by NSA, with help from many others (NRO, Lockheed, Harris, etc) along the way. In all there were some 47 contributors: http://people.redhat.com/swells/gitstats/20140904-scap-security-guide/index… http://people.redhat.com/swells/gitstats/20140904-scap-security-guide/autho… > The first > thing I would want to do is get some idea about if this is supposed to be > about system configuration - what's on-disk. Or is this supposed to be > forensics - what's in kernel memory. Grepping through /etc/audit/audit.rules > is on-dsik config, while auditctl -l is a forensic use. > > Its the same difference as: > systctl -a vs cat /etc/sysctl.conf > mount vs cat /etc/fstab > etc. > > The point I want to make is it sounds like on-disk and forensics is being > mixed. I'd recommend examining /etc/audit/audit.rules instead of auditctl -l. The STIG calls for checking on-disk. In the future you'll likely see checks for static and run-time configuration. >> I would like to share with you some information that was recently >> discovered. RHEL 6.6 was released earlier this month (Oct. 14th). >> >> (1) The audit program and its supported programs (i.e., auditd, auditctl) >> has changed in RHEL 6.6. >> >> RHEL 6.5 >> --------- >> rpm -qa | grep "audit-[[:digit:]]" >> audit-2.2-4.el6_5.x86_64 >> >> RHEL 6.6 >> -------- >> rpm -qa | grep "audit-[[:digit:]]" >> audit-2.3.7-5.el6.x86_64 >> >> >> (2) The output of the command has changed. >> >> RHEL 6.5 >> --------- >> auditctl -l | head -n 2 >> LIST_RULES: exit,always watch=/bin/login perm=x >> LIST_RULES: exit,always arch=1073741827 (0x40000003) key=audit_time_rules >> syscall=adjtimex >> >> RHEL 6.6 >> -------- >> auditctl -l | head -n 2 >> -a never,exit -S all -F path=/var/lib/net-snmp/mib_indexes -F key=exclude >> -a never,exit -S all -F dir=/omd/sites/monnsoc/var/pnp4nagios/perfdata -F >> key=exclude > Yes, it has! This is a much needed change to start getting the rules in a > format that looks like what went into the kernel. The plan is to eventually be > able to do > > auditctl -l > audit.in-kernel > diff -u /etc/audit/audit.rules audit.in-kernel > > so that differences between what's expected and what's enforced can be found. > > Another side effect of this change is that now you can pass -i to auditctl to > get an interpretation of the rule. For example, > > # auditctl -l | grep container-create > -a always,exit -F arch=i386 -S clone -F a0&0x7C020000 -F key=container-create > > becomes > > # auditctl -l -i | grep container-create > -a always,exit -F arch=i386 -S clone -F a0&CLONE_NEWNS|CLONE_NEWUTS| > CLONE_NEWIPC|CLONE_NEWUSER|CLONE_NEWPID|CLONE_NEWNET -F key=container-create > > This lets you verify a complicated rule to make sure you have exactly what you > expected. > > >> (3) In fact, the LIST_RULES tag and format that is present in earlier >> versions of RHEL 6 has been stripped out of the output. Using the strings >> command on the auditctl executable showed me the tags that the auditctl >> program uses in its output. >> >> RHEL 6.5 >> --------- >> strings /sbin/auditctl | grep LIST_RULES >> LIST_RULES >> >> RHEL 6.6 >> -------- >> strings /sbin/auditctl | grep LIST_RULES >> <== No output > This is to be expected. LIST_RULES is a netlink command to the audit system. > It really should not be visible to the outside world. The payload should be, > but not the actual command. > > >> (4) How does this change effect the scanning of the systems for STIG issues? > If it were written for a non-forensics system configuration scan, it should > have no effect. There are two methods of scanning the system: (1) Using OVAL to generate pass/fail reports. The OVAL content is unaffected. It regex's from /etc/audit/audit.rules: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/ch… the code looks like this: > <ind:textfilecontent54_test check="all" > check_existence="at_least_one_exists" > comment="Tests the for presence of 32bit -S adjtime and key" > id="test_audit_rules_time_adjtimex_x86" version="1"> > <ind:object object_ref="obj_audit_rules_time_adjtimex_x86" /> > </ind:textfilecontent54_test> > <ind:textfilecontent54_object id="obj_audit_rules_time_adjtimex_x86" > version="1"> > * <ind:path>/etc/audit</ind:path>** > ** <ind:filename>audit.rules</ind:filename>* > * <ind:pattern ** > ** operation="pattern > match">^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+adjtimex[\s]+.*-k[\s]+[\S]+[\s]*$</ind:pattern>* > <ind:instance datatype="int">1</ind:instance> > </ind:textfilecontent54_object> (2) Some users still perform manual verification, for which is codified as OCIL in the source code: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/sy… aka > <ocil clause="the system is not configured to audit time changes"> > <audit-syscall-check-macro syscall="adjtimex" /> > </ocil> Then we "compile" the STIG, the audit-syscall-check-macro gets extended and transforms the content into the following: > To determine if the system is configured to audit calls to > the |adjtimex| system call, run the following command: > # auditctl -l | grep syscall | grep adjtimex > If the system is configured to audit this activity, it will return a > line. If the system is not configured to audit time changes, this is a > finding. This macro needed to be updated to drop the "grep syscall" Went ahead and patched this now: https://github.com/OpenSCAP/scap-security-guide/pull/317 It'll likely get peer reviewed within the next day. Thanks again for reporting! I've looped in the SCAP Security Guide developer list to give them a heads up on this thread as well. Note SSG serves as the upstream of Red Hat's STIGs, and the code is entirely on GitHub: https://github.com/OpenSCAP/scap-security-guide >> Take the check for STIG-ID RHEL-06-000165 as an example: >> >> RHEL 6.5 >> --------- >> auditctl -l | grep syscall | grep adjtimex >> LIST_RULES: exit,always arch=1073741827 (0x40000003) key=audit_time_rules >> syscall=adjtimex >> LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=audit_time_rules >> syscall=adjtimex >> >> RHEL 6.6 >> -------- >> auditctl -l | grep syscall | grep adjtimex >> <== No output >> >> auditctl -l | grep adjtimex | grep audit_time_rule >> -a always,exit -F arch=i386 -S stime,settimeofday,adjtimex -F >> key=audit_time_rules >> -a always,exit -F arch=x86_64 -S adjtimex,settimeofday,clock_settime -F >> key=audit_time_rules >> >> As you can see the "auditctl -l" command in RHEL 6.5 worked as expected for >> the STIG. This same check didn't work for systems running RHEL 6.6. The >> information above shows why. The output of "auditctl -l" in RHEL 6.6 now >> just shows the contents of the audit.rules file. >> >> >> (5) The below STIG checks are affected by this change. All tools that >> directly use checks indentified in the Red Hat 6 STIG--this includes the >> SCAP. The following checks are affected (there may be others, I just >> looked for checks that had 'grep syscall' in them): >> >> rhel-06-000165 >> rhel-06-000167 >> rhel-06-000169 >> rhel-06-000171 >> rhel-06-000184 >> rhel-06-000185 >> rhel-06-000186 >> rhel-06-000187 >> rhel-06-000188 >> rhel-06-000189 >> rhel-06-000190 >> rhel-06-000191 >> rhel-06-000192 >> rhel-06-000193 >> rhel-06-000194 >> rhel-06-000195 >> rhel-06-000196 >> rhel-06-000197 >> rhel-06-000198 >> rhel-06-000199 >> rhel-06-000200 >> rhel-06-000202

1 0

RHEL7, multiple issues with gdm and disable-user-list
by Crawford, Nicholas P CTR USARMY RDECOM CERDEC (US) 26 Oct '14

26 Oct '14

P { MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px } For those trying to implement login banners and have disabled the user-list feature, I've run in to a couple of issues. 1) With disable-user-list set, once the screen blanks the user is double prompted for a username to login. The first username prompt is ignored and will accept any text. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1157259 2) With disable-user-list set and a banner set, once the screen blanks the banner is lost upon waking the screen. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1157266 The only workaround I've found thus far is to disable session idle for GDM. The unfortunate side effect is the screen never blanks or turns off. echo -e "[org/gnome/desktop/session]\nidle-delay=uint32 0" > /etc/dconf/db/gdm.d/00-fixgdm echo "/org/gnome/desktop/session/idle-delay" > /etc/dconf/db/gdm.d/locks/00-fixgdm-locks dconf update -Nick P.s. if you've already locked down your umask, verify all files are mode 0644, including /etc/dconf/db/gdm. -- Nicholas P. Crawford Senior UNIX Systems Administrator contractor, General Dynamics Information Technology NVESD Network Services Branch, US Army email: Nicholas.Crawford(a)gdit.com comm: (703) 704-2299 dsn: (312) 654-2299 cell: (571) 225-1283

1 0

RHEL7, grub2-mkconfig causes system to boot unpatched release kernel
by Crawford, Nicholas P CTR USARMY RDECOM CERDEC (US) 26 Oct '14

26 Oct '14

P { MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px } Heads up, If you've modified Grub2 settings and ran grub2-mkconfig your system is likely booting the unpatched release kernel 3.10.0-123.el7. I've been using the following as a workaround. CKERN=$(grub2-editenv list | grep saved_entry | cut -d'=' -f2) DKERN=$(cat /etc/grub2.cfg | grep ^menuentry | grep "$CKERN" | awk -F"'" '{print $4}') grub2-set-default "${DKERN}" Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1154430 -Nick -- Nicholas P. Crawford Senior UNIX Systems Administrator contractor, General Dynamics Information Technology NVESD Network Services Branch, US Army email: Nicholas.Crawford(a)gdit.com comm: (703) 704-2299 dsn: (312) 654-2299 cell: (571) 225-1283

1 0

Fwd: [Bug 1066390] Include scap-security-guide in Red Hat Enterprise Linux 6
by Shawn Wells 16 Oct '14

16 Oct '14

You guys. As of yesterday, SSG is now shipping natively in RHEL 6.6! A sampling of included profiles: - RHEL6 STIG (DoD baseline) - CS2 (Ft Meade baseline) - C2S (CIA commercial cloud baseline) - Red Hat CCP (for RHEL cloud images, e.g. Amazon AMIs) - CSCF (MLS baseline used at NRO) The inclusion of SSG is also being picked up by the press, including international sites/magazines: - http://www.zdnet.com/red-hat-enterprise-linux-6-6-arrives-7000034675/ - http://news.softpedia.com/news/Red-Hat-Enterprise-Linux-6-6-Arrives-with-UE… - http://www.admin-magazin.de/News/Red-Hat-Enterprise-Linux-6.6-verfuegbar - http://soft.mail.ru/pressrl_page.php?id=56721 This inclusion reflects almost 3 years of work by the community, and brings RHEL to a point where tooling+content is natively included for STIG compliance. This is exceptionally badass. It's been an amazing ride to get us here -- thank you for everyone who has participated!! For those in the Northern VA/DC/Maryland area, an SSG happy hour is in order. First round on me. Say next Thursday (23-OCT), DuClaws at Arundel Mills? -------- Original Message -------- Subject: [Bug 1066390] Include scap-security-guide in Red Hat Enterprise Linux 6 Date: Tue, 14 Oct 2014 06:42:15 +0000 From: bugzilla(a)redhat.com To: swells(a)redhat.com https://bugzilla.redhat.com/show_bug.cgi?id=1066390 errata-xmlrpc <errata-xmlrpc(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CLOSED Resolution|--- |ERRATA Last Closed| |2014-10-14 02:42:15 --- Comment #42 from errata-xmlrpc <errata-xmlrpc(a)redhat.com> --- Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1471.html -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9Q6ih4rslS&a=cc_unsubscribe -- Shawn Wells Director, Innovation Programs shawn(a)redhat.com | 443.534.0130 @shawndwells

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide October 2014