Bug 231371 - LSPP: audit=0 appears not to disable syscall auditing
LSPP: audit=0 appears not to disable syscall auditing
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Martin Jenner
: OtherQA
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-03-07 17:08 EST by George C. Wilson
Modified: 2010-10-22 09:36 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2007-0959
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 14:43:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch addressing the issues listed above (8.67 KB, patch)
2007-03-09 15:51 EST, Steve Grubb
no flags Details | Diff

  None (edit)
Description George C. Wilson 2007-03-07 17:08:28 EST
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:
Comment 1 Steve Grubb 2007-03-07 17:45:10 EST
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 17:56:56 EST
Ah, that's enlightening. Lemme retry w/o auditd.
Comment 3 George C. Wilson 2007-03-07 19:05:12 EST
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-07 19:47:27 EST
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 10:34:10 EST
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 17:26:35 EST
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 17:37:43 EST
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 17:55:23 EST
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 15:51:04 EST
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 13:54:50 EDT
George, does the current behavior seem OK now? From my point of view, it looks fine.
Comment 11 George C. Wilson 2007-03-26 16:32:34 EDT
George, please verify this.
Comment 12 George C. Wilson 2007-04-03 12:23:33 EDT
This works on the 72 kernel. Closing on our side.
Comment 15 Don Zickus 2007-06-18 11:19:14 EDT
in 2.6.18-28.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 17 John Poelstra 2007-08-27 14:43:01 EDT
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.
Comment 18 George C. Wilson 2007-08-27 18:46:53 EDT
Verified on RHEL 5.1 Snap 3 on ppc64.
Comment 20 errata-xmlrpc 2007-11-07 14:43:05 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.

http://rhn.redhat.com/errata/RHBA-2007-0959.html

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