Bug 231371
| Summary: | LSPP: audit=0 appears not to disable syscall auditing | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | George C. Wilson <ltcgcw> | ||||
| Component: | kernel | Assignee: | Eric Paris <eparis> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Jenner <mjenner> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.0 | CC: | dzickus, eparis, iboverma, linda.knippers, poelstra, sgrubb | ||||
| Target Milestone: | --- | Keywords: | OtherQA | ||||
| Target Release: | --- | ||||||
| Hardware: | powerpc | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | RHBA-2007-0959 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-11-07 19:43:05 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 224041 | ||||||
| Attachments: |
|
||||||
|
Description
George C. Wilson
2007-03-07 22:08:28 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. 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 |