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?

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?

jpo

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
unix-stream("/dev/log");

- 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

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.

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.

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.

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?

(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
patch?

I'm not interested in changing the init script.

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

jpo

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.

Steve,

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

jpo

FYI,

Packaging Draft - InitScripts Proposal
http://fedoraproject.org/wiki/PackagingDrafts/InitScripts

Closing ticket.
No reply to comment #10 in 5 weeks.

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
experiment):

source S1  { udp( ip("0.0.0.0") 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("230.0.0.2") 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.

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.

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(0.0.0.0) 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?

jpo

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
/etc/init.d/syslog-ng.

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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

I've moved off of this project and am no longer in a position to test it against
FC8.

Thank you for your update.