Bug 252358

Summary: Duplicate CONFIG_CHANGE audit records when starting auditd
Product: Red Hat Enterprise Linux 5 Reporter: Linda Knippers <linda.knippers>
Component: kernelAssignee: Eric Paris <eparis>
Status: CLOSED ERRATA QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: high    
Version: 5.1CC: dzickus, poelstra, rkenna, sgrubb
Target Milestone: ---Keywords: OtherQA, Regression
Target Release: ---   
Hardware: All   
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:59:22 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:
Attachments:
Description Flags
Possible solution none

Description Linda Knippers 2007-08-15 16:15:44 UTC 
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.
kernel-2.6.18-36.el5
audit-1.5.5-4.el5
selinux-policy-2.4.6-80.el5
selinux-policy-mls-2.4.6-80.el5

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

How reproducible:
Very.

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

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

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 18:10:39 UTC 
Created attachment 161389 [details]
Possible solution

broken by this upstream patch we took into 5.1

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6a01b07fae482f9b34491b317056c89d3b96ca2e


the audit record without a sid should be conditionalized on there actually not
being a sid.
Comment 2 Linda Knippers 2007-08-15 18:18:34 UTC 
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 18:21:56 UTC 
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 18:35:29 UTC 
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 19:23:16 UTC 
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 17:49:41 UTC 
I testing this with RHEL5 U1 snapshot 6 and it seems to be fixed.
Comment 11 errata-xmlrpc 2007-11-07 19:59:22 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.

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