Description of problem: Set audit=0 on the command line. Syscall auditing is still enabled. Version-Release number of selected component (if applicable): Linux hvracer4.ltc.austin.ibm.com 2.6.18-8.el5.lspp.67 #1 SMP Mon Feb 26 11:24:30 EST 2007 ppc64 ppc64 ppc64 GNU/Linux How reproducible: Boot the lspp.67 kernel with RHEL5 GM 20070208 and pass audit=0 as a kernel parm. Audit is not disabled. Check the audit log. Add a syscall rule. It still gets audited. I also tried passing audit=0 selinux=0 but still got syscall audit records. Not sure if this true for all syscalls. Steps to Reproduce: 1. Load a machine with RHEL5 GM 20070208 with LSPP kickstart. 2. Install the lspp.67 kernel. 3. Boot with audit=0. 4. Add a syscall audit rule - auditctl -a entry,always -S open. 5. Open a file. 6. Check the audit log. 7. You will find an open audit record. Actual results: Get an open() audit record. Expected results: Don't get an open() audit record. Additional info:
Is your audit daemon running? (It enables the audit system when it starts up.) To properly test this, you'd want to chkconfig --del auditd then reboot and then do your test, but look in syslog for open's events.
Ah, that's enlightening. Lemme retry w/o auditd.
I did the chkconfig --del auditd and booted once again with audit=0. Surprisingly, I still see the open syscall audit record. It gets written to the console. auditctl -s shows AUDIT_STATUS: enabled=0 flag=1 pid=0 . . . and cat /proc/cmdline in fact shows the audit=0.
It seems to work as expected on x86_64. Must be ppc specific. This would be a kernel problem and not user space, so re-assiging.
FYI - On ia64 I get an audit record for the rule being added but I don't get an audit record any subsequent opens.
Yes, Linda is right. I confirmed that I'm seeing a record for the add, not the actual open syscall. I looked at stale data that had open syscall records. I cleared the log and just see only the add records. So this is working correctly assuming audit=0 is only supposed to turn off syscall records.
I recommend this bug be closed as notabug if the add records shouldn't be suppressed by audit=0.
when audit=0, you really are not supposed to get any records. I think there is a missing "if (audit_enabled)" before sending the add rule event. I bet the same check is missing for rule delete. But, you should not get any records at all except maybe selinux avcs. I think there's an exception for them.
Created attachment 149726 [details] Patch addressing the issues listed above This patch was posted to linux-audit mail list.
George, does the current behavior seem OK now? From my point of view, it looks fine.
George, please verify this.
This works on the 72 kernel. Closing on our side.
in 2.6.18-28.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot3 on partners.redhat.com. Requested action: Please verify that your issue is fixed as soon as possible to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. More assistance: If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
Verified on RHEL 5.1 Snap 3 on ppc64.
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/RHBA-2007-0959.html