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): audit-1.0.4-1.EL4 How reproducible: Always Steps to Reproduce: 1. See attached test case 2. 3. Actual Results: Only successful syscalls where in the audit log. Expected Results: Only failed syscalls should be in the audit log. Additional info:
Created attachment 121944 [details] Testcase demonstrating the problem You need to give the test one argument: a valid, non-root user.
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 2.6.9-11.EL.audit.88 So...what kernel are you using?
This sounds like an older bug which I thought was fixed... Please try "success!=1" instead of "success=0" as a workaround.
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 syscalls. Amy noticed that the code in this area is different in David's git tree.
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?
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.
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?
We haven't tried patching the kernel yet. We were waiting to hear if there is a fix (documentation or otherwise) before proceeding.
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.
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> To: Linux Audit Discussion <linux-audit> [...] 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; [...]
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.
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.
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.
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. http://rhn.redhat.com/errata/RHSA-2006-0132.html