Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 231371 - LSPP: audit=0 appears not to disable syscall auditing
Summary: LSPP: audit=0 appears not to disable syscall auditing
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: powerpc
OS: Linux
Target Milestone: ---
: ---
Assignee: Eric Paris
QA Contact: Martin Jenner
Depends On:
Blocks: RHEL5LSPPCertTracker
TreeView+ depends on / blocked
Reported: 2007-03-07 22:08 UTC by George C. Wilson
Modified: 2018-10-19 22:48 UTC (History)
6 users (show)

Fixed In Version: RHBA-2007-0959
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-11-07 19:43:05 UTC
Target Upstream Version:

Attachments (Terms of Use)
Patch addressing the issues listed above (deleted)
2007-03-09 20:51 UTC, Steve Grubb
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0959 normal SHIPPED_LIVE Updated kernel packages for Red Hat Enterprise Linux 5 Update 1 2007-11-08 00:47:37 UTC

Description George C. Wilson 2007-03-07 22:08:28 UTC
Description of problem:

Set audit=0 on the command line. Syscall auditing is still enabled.

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

Linux 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:

Comment 1 Steve Grubb 2007-03-07 22:45:10 UTC
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.

Comment 2 George C. Wilson 2007-03-07 22:56:56 UTC
Ah, that's enlightening. Lemme retry w/o auditd.

Comment 3 George C. Wilson 2007-03-08 00:05:12 UTC
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.

Comment 4 Steve Grubb 2007-03-08 00:47:27 UTC
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.

Comment 5 Linda Knippers 2007-03-08 15:34:10 UTC
FYI - On ia64 I get an audit record for the rule being added but I don't
get an audit record any subsequent opens. 

Comment 6 George C. Wilson 2007-03-08 22:26:35 UTC
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.

Comment 7 George C. Wilson 2007-03-08 22:37:43 UTC
I recommend this bug be closed as notabug if the add records shouldn't be
suppressed by audit=0.

Comment 8 Steve Grubb 2007-03-08 22:55:23 UTC
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.

Comment 9 Steve Grubb 2007-03-09 20:51:04 UTC
Created attachment 149726 [details]
Patch addressing the issues listed above

This patch was posted to linux-audit mail list.

Comment 10 Steve Grubb 2007-03-23 17:54:50 UTC
George, does the current behavior seem OK now? From my point of view, it looks fine.

Comment 11 George C. Wilson 2007-03-26 20:32:34 UTC
George, please verify this.

Comment 12 George C. Wilson 2007-04-03 16:23:33 UTC
This works on the 72 kernel. Closing on our side.

Comment 15 Don Zickus 2007-06-18 15:19:14 UTC
in 2.6.18-28.el5
You can download this test kernel from

Comment 17 John Poelstra 2007-08-27 18:43:01 UTC
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot3 on  

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, please contact your Partner Manager.

Comment 18 George C. Wilson 2007-08-27 22:46:53 UTC
Verified on RHEL 5.1 Snap 3 on ppc64.

Comment 20 errata-xmlrpc 2007-11-07 19:43:05 UTC
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.