Bug 175132 - Audit fails to record syscall failures when asked to via auditctl
Audit fails to record syscall failures when asked to via auditctl
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Steve Grubb
Brian Brock
: Regression
Depends On:
Blocks: 168429 175195 175213
  Show dependency treegraph
Reported: 2005-12-06 16:10 EST by Paul Moore
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: RHSA-2006-0132
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 15:59:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Testcase demonstrating the problem (898 bytes, text/plain)
2005-12-06 16:12 EST, Paul Moore
no flags Details

  None (edit)
Description Paul Moore 2005-12-06 16:10:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
When trying to set an audit filter to catch all instances of a failed syscall using the auditctl tool only successful syscalls appear in the audit log.  Filtering based on successful syscalls works as expected.  The auditctl command line I am using is below:

 # auditctl -a exit,always -S open -F success=0

I will attach a simple test which will demonstrate the problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. See attached test case

Actual Results:  Only successful syscalls where in the audit log.

Expected Results:  Only failed syscalls should be in the audit log.

Additional info:
Comment 1 Paul Moore 2005-12-06 16:12:20 EST
Created attachment 121944 [details]
Testcase demonstrating the problem

You need to give the test one argument: a valid, non-root user.
Comment 2 Steve Grubb 2005-12-06 17:04:34 EST
I don't get the same results. I did make a couple minor changes. (I don't like
clearing the audit log like the script does.)

[root@endeavor ~]# ausearch -ts 17:04:41 -sc open -f filter_bug_test
time->Tue Dec  6 17:04:47 2005
type=PATH msg=audit(1133906687.566:977): name="/tmp/filter_bug_test.txt"
flags=101  inode=16 dev=03:08 mode=0100600 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1133906687.566:977):  cwd="/root"
type=SYSCALL msg=audit(1133906687.566:977): arch=40000003 syscall=5 success=no
exit=-13 a0=bff41c24 a1=8000 a2=0 a3=8000 items=1 pid=2991 auid=4325 uid=4325
gid=4325 euid=4325 suid=4325 fsuid=4325 egid=4325 sgid=4325 fsgid=4325
comm="cat" exe="/bin/cat"

[root@endeavor ~]# uname -r

So...what kernel are you using?
Comment 3 Klaus Weidner 2005-12-06 17:05:53 EST
This sounds like an older bug which I thought was fixed...

Please try "success!=1" instead of "success=0" as a workaround.
Comment 4 Linda Knippers 2005-12-06 17:17:34 EST
We're running 2.6.9-22.0.1.EL.audit.1 with the audit tools that Paul
mentioned in the report.

When I try with "success!=1" I see the audit records for the failed

Amy noticed that the code in this area is different in David's git tree.
Comment 5 Steve Grubb 2005-12-06 17:39:06 EST
Regarding comment #3, I think you are right, this rings a bell. I think I wanted
a code fix and everyone else wanted a documentation fix. Do you remember what
the underlying bug was?
Comment 6 Linda Knippers 2005-12-06 17:44:14 EST
The underlying bug seems to be in the kernel in audit_filter_rules (where the
code is different in David's tree) and perhaps in auditctl the way it sends
the value to filter on.  

If there was a documentation fix, where is it documented?  The manpage 
says use 0 and 1.
Comment 7 Steve Grubb 2005-12-06 17:52:29 EST
Linda, it was in someone else's evaluation.

I'm still trying to see if this is kernel or audit package that's causing this.
have you patched a kernel to make sure the difference is the bug fix?
Comment 8 Linda Knippers 2005-12-06 17:55:34 EST
We haven't tried patching the kernel yet.  We were waiting to hear if there
is a fix (documentation or otherwise) before proceeding. 
Comment 9 Steve Grubb 2005-12-06 18:01:07 EST
Linda, the doc fix is to tell the users to use success as klaus said. I
personally disagree with that. This is one of those cases where a doc fix came
back to bite us.

In any event, .88 and 1.0.12 works fine for me.
Comment 10 Klaus Weidner 2005-12-06 18:49:48 EST
There was some discussion about this around Aug 24th on the linux-audit list,
it's a kernel problem.

The way I remember, the assumption had been that this was going to be fixed in
the kernel to match the documentation. Any documentation workaround was supposed
to be a temporary stopgap until the kernel was fixed, not something to add
permanently to the package documentation.

Apparently the kernel change Steve proposed (see mail below) never actually made
it into the kernel :-(

Date: Wed, 24 Aug 2005 10:40:47 -0400
Subject: Re: audit 1.0.3 released
From: Steve Grubb <sgrubb@redhat.com>
To: Linux Audit Discussion <linux-audit@redhat.com>


There is a kernel bug in my opinion (auditsc.c):

442     case AUDIT_SUCCESS:
443         if (ctx && ctx->return_valid)
444             result = (ctx->return_valid == AUDITSC_SUCCESS);
445         break;

This doesn't use the value that was passed into the kernel. I think this
should be:

442     case AUDIT_SUCCESS:
443         if (ctx && ctx->return_valid)
444             result = (ctx->return_valid == AUDITSC_SUCCESS) == value;
445         break;

Comment 11 Linda Knippers 2005-12-06 19:25:22 EST
The problem does seem to be fixed in the .88 kernel, just not in the
kernel we're using.  I assume that means its fixed in U3.
Comment 15 Linda Knippers 2005-12-07 12:31:13 EST
BTW, I just verified that with the .88 kernel and the 1.0.4+auditctlfix
audit tools, the problem doesn't exist.  

If we could get this fix (Patch20074: linux-2.6.9-audit-success-failure.patch)
pulled into our certification kernel, that would be great.  Otherwise we'll
have to go with a documentation fix.
Comment 17 Andrius Benokraitis 2005-12-13 13:24:22 EST
Paul, thanks for making Red Hat aware of this - the patch has been included in
the latest spin of the RHEL4 U3 kernel, and should be released shortly.
Comment 19 Red Hat Bugzilla 2006-03-07 15:59:29 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.