Red Hat Bugzilla – Bug 252358
Duplicate CONFIG_CHANGE audit records when starting auditd
Last modified: 2009-06-19 20:11:33 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.
Steps to Reproduce:
1.Configure a system using the MLS policy using the lspp kickstart file
2.Boot the system
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
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
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
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
Created attachment 161389 [details]
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.
That certainly looks like it. We should see the same problem with
targeted policy since even with targeted policy, there's a sid.
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.
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-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.
I testing this with RHEL5 U1 snapshot 6 and it seems to be fixed.
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.