Bug 252358 - Duplicate CONFIG_CHANGE audit records when starting auditd
Duplicate CONFIG_CHANGE audit records when starting auditd
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Eric Paris
Martin Jenner
: OtherQA, Regression
Depends On:
  Show dependency treegraph
Reported: 2007-08-15 12:15 EDT by Linda Knippers
Modified: 2009-06-19 20:11 EDT (History)
4 users (show)

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

Attachments (Terms of Use)
Possible solution (2.02 KB, patch)
2007-08-15 14:10 EDT, Eric Paris
no flags Details | Diff

External Trackers
Tracker 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-07 19:47:37 EST

  None (edit)
Description Linda Knippers 2007-08-15 12:15:44 EDT
Description of problem:
I'm running the RHEL5.1 public beta using the LSPP configuration
with the mls policy.  When I boot the system or restart the auditd,
I see duplicates of the CONFIG_CHANGE records, some which don't
have the subj= field. 

I don't see the same behavior on systems running the RHEL5+lspp packages
from our LSPP evaluation so this seems like a regression.

Version-Release number of selected component (if applicable):
I'm running just packages from the U1 Beta.  I have not updated
to snap 1.

The audit.rules file is as shipped, with no modifications.

How reproducible:

Steps to Reproduce:
1.Configure a system using the MLS policy using the lspp kickstart file
2.Boot the system
Actual results:

Note that the CONFIG_CHANGE messages come in pairs, one without the subj=

type=DAEMON_START msg=audit(1185888960.325:2588) auditd start, ver=1.5.5,
format=raw, auid=4294967295 pid=2577 res=success, auditd pid=2577
type=CONFIG_CHANGE msg=audit(1185888960.425:404): audit_enabled=1 old=0 by
auid=4294967295 subj=system_u:system_r:auditd_t:s15:c0.c1023 res=1
type=CONFIG_CHANGE msg=audit(1185888960.425:405): audit_enabled=1 old=0 by
auid=4294967295 res=1
type=CONFIG_CHANGE msg=audit(1185888960.446:406): audit_backlog_limit=320 old=64
by auid=4294967295 subj=system_u:system_r:auditctl_t:s0-s15:c0.c1023 res=1
type=CONFIG_CHANGE msg=audit(1185888960.446:407): audit_backlog_limit=320 old=64
by auid=4294967295 res=1

Expected results:

This is from our evaluated config:

type=DAEMON_START msg=audit(1187190862.721:7111) auditd start, ver=1.3.1,
format=raw, auid=4294967295 pid=1750 res=success, auditd pid=1750
type=CONFIG_CHANGE msg=audit(1187190862.822:8): audit_enabled=1 old=0 by
auid=4294967295 subj=system_u:system_r:auditd_t:s15:c0.c1023
type=CONFIG_CHANGE msg=audit(1187190862.858:9): audit_backlog_limit=256 old=64
by auid=4294967295 subj=system_u:system_r:auditctl_t:s0-s15:c0.c1023

Additional info:
Comment 1 Eric Paris 2007-08-15 14:10:39 EDT
Created attachment 161389 [details]
Possible solution

broken by this upstream patch we took into 5.1


the audit record without a sid should be conditionalized on there actually not
being a sid.
Comment 2 Linda Knippers 2007-08-15 14:18:34 EDT
That certainly looks like it.  We should see the same problem with
targeted policy since even with targeted policy, there's a sid.
Comment 3 Eric Paris 2007-08-15 14:21:56 EDT
Patch in comment #1 will fix the problem but won't audit anything if the sid to
context translation fails.  Another patch that is correct to come shortly.
Comment 6 Don Zickus 2007-08-21 14:35:29 EDT
in 2.6.18-42.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 8 John Poelstra 2007-09-11 15:23:16 EDT
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot6 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed ASAP to confirm that it
will be 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.

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 9 Linda Knippers 2007-09-13 13:49:41 EDT
I testing this with RHEL5 U1 snapshot 6 and it seems to be fixed.
Comment 11 errata-xmlrpc 2007-11-07 14:59:22 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.


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