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/html/6.6_Technical_Notes/RHEA-2014-1471.html 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.html http://people.redhat.com/swells/gitstats/20140904-scap-security-guide/authors.html > 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/checks/audit_rules_time_adjtimex.xml#L28#L56 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/system/auditing.xml#L504#L506 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
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
