Bug 222195 - syslogd_disable_trans=1 labels /dev/log as device_t
syslogd_disable_trans=1 labels /dev/log as device_t
Product: Fedora
Classification: Fedora
Component: syslog-ng (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Douglas E. Warner
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-01-10 15:29 EST by Steve Friedman
Modified: 2008-05-01 17:36 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-01 17:36:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Friedman 2007-01-10 15:29:11 EST
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. After box is on, type "restorecon /dev/log" and (via ls -lZ /dev/log) verify
that type is devlog_t.
2. Restart box.
Actual results:
ls -lZ /dev/log returns device_t

Expected results:
expected devlog_t (as per restorecon)

Additional info:
Adding restorecon /dev/log in /etc/init.d/syslog_ng right after starting the
daemon (actually, right after setting retval) works around the problem.
Comment 1 Jose Pedro Oliveira 2007-01-10 15:44:29 EST
I have syslog-ng installed in two systems (FC-5 and FC-6) and never had problems
with SELinux.

In both machines the /dev/log entry belongs to the devlog_t context and in both
machines syslog-ng ios the default logging daemon.

Also none of the syslog-ng packages in FE modified the core SELinux policies.

[FC-5] $ ls -Z /dev/log
srw-rw-rw-  root root system_u:object_r:devlog_t       /dev/log

[FC-6] $ $ ls -Z /dev/log
srw-rw-rw-  root root system_u:object_r:devlog_t       /dev/log

Can you reproduce the problem in a clean system?

Comment 2 Jose Pedro Oliveira 2007-01-10 15:50:56 EST
Re-opening the ticket (I closed it by mistake).

Could you also post the contents of /etc/sysconfig/selinux and versions of the
selinux rpms?

Comment 3 Steve Friedman 2007-01-10 17:11:05 EST
This system was installed last week, I'm only now starting to modify the system
so it is fairly clean.  I'll answer the questions you asked, but first want to
mention the following (which seem important to me):

- rpm -qV syslog-ng shows that /etc/init.d/syslog-ng and
/etc/syslog-ng/syslog-ng.conf were modified.  (The former (at least) because I
added the restorecon and the latter because I added other logging.)

- I included an 'ls -lZ /dev/log' just prior to starting the daemon (in
/etc/init.d/syslog-ng) and got an error stating that /dev/log did not exist. 
So, this file was being created during syslog-ng's execution of

- dmesg did not seem like the most convenient way of showing the startup order
of the various scripts.  Is there a better way?

Your questions:

- selinux-policy-2.4.6-17.fc6 (and selinux-policy-targeted)
- libselinux-1.33.2-3.fc6 (and libselinux-devel and libselinux-python)

the config is enforcing/targeted/0
Comment 4 Steve Friedman 2007-01-11 09:35:46 EST
I expect to be doing a clean install of a new machine next week.  However, one
other data point.  I have syslogd_disable_trans=1.
Comment 5 Steve Friedman 2007-01-17 12:16:54 EST
I can confirm that (on a clean install), setting syslogd_disable_trans=1 causes
/dev/log to be labelled as device_t instead of dev_log_t.  I've updated the summary.
Comment 6 Steve Friedman 2007-01-29 16:58:59 EST
I e-mailed this BZ number on the selinux mailing list, but no one from the
selinux group added themselves to this bug.  I don't know whether it makes sense
to reassign it to them (even if it is necessary to close this bug and open a new
one) or what.  Please advise how you prefer to handle it.
Comment 7 Steve Friedman 2007-02-22 13:16:46 EST
Dan Walsh closed this bug as WONTFIX.

Unfortunately, we use syslog-ng to redistribute log messages in a fairly dynamic
manner (and thus can't keep up with the avc messages).  The workaround that I've
been forced to maintain is to add /sbin/restorecon /dev/log in the init.d script.

Would it be possible to update the syslog-ng init.d script with this one-line patch?
Comment 8 Jose Pedro Oliveira 2007-02-26 15:26:24 EST
(In reply to comment #7)
> Dan Walsh closed this bug as WONTFIX.
> Unfortunately, we use syslog-ng to redistribute log messages in a fairly dynamic
> manner (and thus can't keep up with the avc messages).  The workaround that I've
> been forced to maintain is to add /sbin/restorecon /dev/log in the init.d script.
> Would it be possible to update the syslog-ng init.d script with this one-line

I'm not interested in changing the init script.

Exactly what kind of operations are you doing? And what AVCs are you getting?

Comment 9 Steve Friedman 2007-02-26 16:56:00 EST
We are constantly updating syslog-ng.conf to distribute packets from various udp
ports to various other applications and/or destination machines.  So, 
syslogd_disable_trans=0 fails because various udp ports can't be opened, or
various log files can't be opened/written to, or various applications can't be
started, etc.  And, since syslog-ng.conf never stabilizes, it is rather hard to
use audit2allow.

On the other hand, with syslogd_disable_trans=1, then (as Dan Walsh says in bug
229599) nothing else can log to /dev/log.  Basically, syslogd_disable_trans is a
broken concept and needs to be replaced.
Comment 10 Jose Pedro Oliveira 2007-02-26 17:54:07 EST

Could you attach a couple of configuration examples? Maybe starting with
UDP ones?

Comment 11 Jose Pedro Oliveira 2007-02-27 16:12:16 EST

Packaging Draft - InitScripts Proposal
Comment 12 Jose Pedro Oliveira 2007-04-04 12:47:46 EDT
Closing ticket.
No reply to comment #10 in 5 weeks.
Comment 13 Steve Friedman 2007-04-06 16:20:15 EDT
Sorry for the delay, I got dumped into a crisis and am only now making my way
through my backlogged items.

I understand (and agree with) the initscripts proposal.  This issue is clearly a
workaround until selinux develops a better boolean that enables syslog-ng to run
unconstrained while still creating /dev/log with the correct labeling.

In any event, back to your request from #10:

We usually use one type of source (although the port can change depending on the

source S1  { udp( ip("") port (8996) ); };

We usually use a couple of destinations:

; a file destination to post-analyze the data
destination D1 { file("blah"); };

; one or more outputs, based upon filters to forward data to various other
equipment that is connected.  The output patterns change for different
experiments.  We use both multicast addresses (with localip) and unicast (with
udp or tcp, as the case may be).

destination D2m { udp("") localip(addr) port(8997) ); };
destination D2u { udp("one_destination_machine") port(8997) ); };

; finally, we occasionally use a local program:
destination D3 { program("reliable_local_data_consumer"); };

Sometimes, different destinations require different templates, sometimes the
input ports are not configurable, etc.  Sometimes, the destinations can't handle
receiving everything, so we use syslog-ng to carefully filter out the
problematic log messages.

The net result is that we can't develop a reasonable selinux policy, but the
current selinux boolean doesn't label /dev/log correctly.
Comment 14 Jose Pedro Oliveira 2007-04-07 16:32:27 EDT
syslogd_disable_trans boolean
Fedora Core 7 selinux-policy version 2.5.11 (selinux-policy-2.5.11-4.fc7) no
longer has the "syslogd_disable_trans" boolean.
Comment 15 Jose Pedro Oliveira 2007-04-07 17:07:19 EDT
UDP sources and destinations ports other than 514

In FC-6 (and in FC-7) you should be able to use the semanage command to
authorize ports (UDP and TCP) other than 514:

  * semanage port -a -t syslogd_port_t -p udp 1514 

  * semanage port -a -t syslogd_port_t -p tcp 1514 

  * semanage port -a -t syslogd_port_t -p udp 9000-9100

  * semanage port -l 

UDP source example

Configuration line:

  source s_udp { udp(ip( port(8514)); };

SELinux command

  semanage port -a -t syslogd_port_t -p udp 8514

You should be able to solve the UDP/TCP ports usage (source and destinations)
with the semanage command.  Could you give it a try?

Comment 16 Steve Friedman 2007-04-12 15:01:58 EDT
I've opened up most of the source ports my users tend to use, now I'll try to
figure out how to authorize execute access to scripts / write access to
directories.  ("semanage fcontext" was giving me errors.)  Perhaps, I'll be able
to generalize things sufficiently so my users (some of whom would be perfectly
happy to run with everything 0777) won't complain.  In the meantime, I wrote an
init.d script that ensures that the necessary restorecon command exists in
Comment 17 Bug Zapper 2008-04-04 01:33:41 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 18 Steve Friedman 2008-04-15 21:32:10 EDT
I've moved off of this project and am no longer in a position to test it against
Comment 19 John Poelstra 2008-05-01 17:36:39 EDT
Thank you for your update.

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