Red Hat Bugzilla – Bug 231371
LSPP: audit=0 appears not to disable syscall auditing
Last modified: 2018-10-19 18:48:41 EDT
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
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.
Get an open() audit record.
Don't get an open() audit record.
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.
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.