[gov-sec] The output of auditctl has changed in RHEL 6.6

Shawn Wells shawn at redhat.com
Wed Oct 29 01:49:58 UTC 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20141028/cc20ab92/attachment.html>


More information about the scap-security-guide mailing list