Description of problem: multiple SELinux denials when upgrading RHEL4-U6 to latest RHEL4-U7 Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.30-2.149 How reproducible: 100% Steps to Reproduce: 1. Install RHEL4-U6::AS 2. update to RHEL4-U7 using up2date 3. Actual results: audit(1210322735.868:2): avc: denied { read } for pid=28252 comm="minilogd" name="firefox-3.0-0.beta5.3.el4.ppc.rpm" dev=0:14 ino=10291966 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:nfs_t tclass=file audit(1210322735.871:3): avc: denied { read } for pid=28252 comm="minilogd" name="gcc-3.4.6-10.ppc.rpm" dev=0:14 ino=14445753 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:nfs_t tclass=file audit(1210322735.874:4): avc: denied { read } for pid=28252 comm="minilogd" name="gcc-c++-3.4.6-10.ppc.rpm" dev=0:14 ino=14445754 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:nfs_t tclass=file audit(1210322735.877:5): avc: denied { read } for pid=28252 comm="minilogd" name="gcc-c++-ppc32-3.4.6-10.ppc.rpm" dev=0:14 ino=14445755 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:nfs_t tclass=file Expected results: no selinux denials Additional info:
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
These look like leaked file descriptors. minilogd does not know anything about the var_lock file or any of these other open files. I believe what ever is execing a restart of the minilogd is leaking a file descriptor. Potentially the rhts test itself.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Dan ... this is not tested via RHTS, but rather manually from a ssh session or console using the `up2date` command. Can we get your help in crafting up the release note for beta customers that see this issue?
SELinux detects leaked file descriptors and closes them on exec. When confined applications are started with inherited open file descriptors, the SELinux kernel checks whether the confined application has access. If the application is not allowed access, the kernel closes the open file descriptor and reopens it connected to /dev/null. It then reports the AVC. In most cases this is just a bug in the application that executed the confined application and can be ignored from both a security point of view and the confined application will work properly.
1) Having those specific file descriptors open would likely be an up2date or rpm bug 2) The only way that minilogd would be started (theoretically) is in a very small window where the syslog daemon is being restarted
Is this bug relevant: #247601 I remember these leaking descriptors in yum (urlgrabber I think). Does up2date use urlgrabber or it's a completely separate issue?
thanks Alex. adding to RHEL4.7 release notes under "Installation-Related Notes": <quote> When upgrading from Red Hat Enterprise Linux 4.6 to this release, minilogd may log several SELinux denials. These error logs are harmless, and can be safely ignored. </quote> please advise if any further revisions are required. thanks!
Hi, the RHEL4.7 release notes deadline is on June 17, 2008 (Tuesday). they will undergo a final proofread before being dropped to translation, at which point no further additions or revisions will be entertained. a mockup of the RHEL4.7 release notes can be viewed here: http://intranet.corp.redhat.com/ic/intranet/RHEL4u7relnotesmockup.html please use the aforementioned link to verify if your bugzilla is already in the release notes (if it needs to be). each item in the release notes contains a link to its original bug; as such, you can search through the release notes by bug number. Cheers, Don
Throwing back to initscripts for minilogd. Sorry - I am not sure here that anyone has prooven or shown that there is a bug in up2date that needs addressing, in that up2date is doing something wrong, vs manual rpm command upgrade. If so, please re-state in a sane fashion before punting over. Thanks, Cliff.
All the files that are trying to be accessed are the RPM files involved in the transaction, and a file named 'transaction' on the root filesystem. The only file that is ever opened in minilogd is /dev/null, and a non-fs socket to talk to syslogd. Ergo, these file descriptors are inherited from something running the transaction. That means up2date or the rpm libraries. Most likely whichever one is responsible for the 'transaction' file. Bouncing back to up2date for now; feel free to move to RPM.
Has anyone looked into BZ referenced in comment #11? Is it relevant or not?
Alex, can you please try this as Panu describes, with rpm rather than up2date, and see if it reproduces?
oops - sorry set needinfo on QAcontact, should have been Alex
Moving to 4.8 since the release note is already in place and 4.7 is about out the door.
(In reply to comment #20) > Alex, can you please try this as Panu describes, with rpm rather than up2date, > and see if it reproduces? Hmmm, tried with `rpm -Uhv --force *.rpm' in the directory containing the rpms for the newest release but didn't see selinux denials.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When upgrading from Red Hat Enterprise Linux 4.6 to this release, minilogd may log several SELinux denials. These error logs are harmless, and can be safely ignored.
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 therefore 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-2009-0951.html