Bug 694462 - setroubleshootd must not be started before rsyslog
Summary: setroubleshootd must not be started before rsyslog
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: setroubleshoot
Version: 5.5
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-07 13:09 UTC by Gunther Schlegel
Modified: 2013-04-24 19:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-24 19:48:04 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Gunther Schlegel 2011-04-07 13:09:32 UTC
Description of problem:
When using rsyslog instead of sysklogd on RHEL >= 5.5, setroubleshootd is 
started before rsyslog and is therefore unable to bind to the logging socket. As a result, setroubleshootd does not work.


Version-Release number of selected component (if applicable):
setroubleshoot-2.0.5-5.el5

How reproducible:
Enable SElinux
Uninstall sysklogd
Install rsyslog, setroubleshoot
Reboot
Create an SELinux denial
Try to solve it using setroubleshoot


Actual results:
setroubleshootd does not report any SElinux denies in /var/log/messages


Expected results:
setroubleshootd should log an explaination of the AVC denial in /var/log/messages.


Additional info:
As of RHEL 5.5, some init scripts, including rsyslog's one, include additional LSB startup information: 

(taken from /etc/init.d/rsyslog)
### BEGIN INIT INFO
# Provides: $syslog
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Stop: 0 1 2 3 4 5 6
# Short-Description: Enhanced system logging and kernel message trapping daemons
# Description: Rsyslog is an enhanced multi-threaded syslogd supporting, 
#              among others, MySQL, syslog/tcp, RFC 3195, permitted 
#              sender lists, filtering on any message part, and fine 
#              grain output format control.
### END INIT INFO

The defined chkconfig start position for both sysklogd and rsyslog is 12. However, chkconfig additionally processes the LSB information if present and the service providing the $remote_fs dependency (netfs) is only started at position 25. As a result, rsyslog is started at position 26. setroubleshootd is started at position 23, though.

sysklogd installations are not affected, as they do not contain any additional LSB dependencies (yet) and are still started at position 12.

There are a couple of ways to fix this. One might question whether rsyslogd should be started after netfs at all, as 26 is quite late for a basic service like syslog. Giving up the $remote_fs dependency and moving rsyslog back to position 12 would solve the issue.

Adding a LSB-style dependency on $syslog to /etc/rc.d/init.d/setroubleshoot is less invasive, though and would let chkconfig deal with the startup ordering.

One might also just move setroubleshoot to position 27.

Comment 1 Daniel Walsh 2011-04-07 14:17:31 UTC
setroubleshoot relies on the audit system not the syslog system

Comment 2 Gunther Schlegel 2011-04-07 14:34:29 UTC
It reads from the audit system and logs to the syslog system.

Comment 3 Daniel Walsh 2011-04-07 14:51:05 UTC
I would say this is an rsyslog or bug.

Comment 4 Tomas Heinrich 2013-03-14 15:17:34 UTC
Karel, thanks for bringing this up. Too bad it's this late in the life-cycle.

At the time of filing this bz, the rsyslog package had files located under /usr, which could be mounted over network. That was probably the reason for depending on $remote_fs.

Since RHEL 5.8, all the binaries and modules were moved out of /usr, so the dependency is probably not needed anymore. As of now, the package in RHEL 6 only depends on $local_fs.

I'm not sure if it's worth changing as it's really late, given that nobody else complained and given that this looks more like a setroubleshoot bug. :]

If setroubleshoot needs syslog, it should depend on it.


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