Description of problem: syslog-ng being denied write access to var_t (/var). Not sure if this is an error in policy or that syslog-ng is doing something incorrectly or unneeded. Version-Release number of selected component (if applicable): selinux-policy-3.0.8-76.fc8 syslog-ng-2.0.7-1.fc8 I got an AVC denial (pasted below) that seemed strange for the system logger; in addition, it may be the reason behind why logging did not begin after syslog-ng restarted the log file this morning. The logfile also has an unusual looking security context, which restorecon -Rv did not change: -rw------- root root unconfined_u:object_r:var_log_t /var/log/messages OTOH, that may be because I changed to using syslog-ng after updating this machine to Fedora 8 from Fedora 7. The below denial occurs when restarting syslog-ng: Jan 27 14:46:14 calliope syslog-ng[3814]: Termination requested via signal, terminating; Jan 27 14:46:14 calliope syslog-ng[3814]: syslog-ng shutting down; version='2.0.7' Jan 27 14:46:14 calliope syslog-ng[4150]: syslog-ng starting up; version='2.0.7' Jan 27 14:46:16 calliope setroubleshoot: SELinux is preventing /sbin/syslog-ng (syslogd_t) "write" to <Unknown> (var_t). For complete SELinux messages. run sealert -l 65230ce2-d1d0-428c-b905-b5450db1a322 Here is the full alert: sealert -l 65230ce2-d1d0-428c-b905-b5450db1a322 Summary SELinux is preventing /sbin/syslog-ng (syslogd_t) "write" to <Unknown> (var_t). Detailed Description SELinux denied access requested by /sbin/syslog-ng. It is not expected that this access is required by /sbin/syslog-ng and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for <Unknown>, restorecon -v <Unknown> If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context unconfined_u:system_r:syslogd_t Target Context system_u:object_r:var_t Target Objects None [ dir ] Affected RPM Packages syslog-ng-2.0.7-1.fc8 [application] Policy RPM selinux-policy-3.0.8-76.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name calliope.phig.org Platform Linux calliope.phig.org 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 EST 2007 i686 i686 Alert Count 2 First Seen Sun Jan 27 14:41:26 2008 Last Seen Sun Jan 27 14:46:14 2008 Local ID 65230ce2-d1d0-428c-b905-b5450db1a322 Line Numbers Raw Audit Messages avc: denied { write } for comm=syslog-ng dev=dm-0 egid=0 euid=0 exe=/sbin /syslog-ng exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=var pid=3814 scontext=unconfined_u:system_r:syslogd_t:s0 sgid=0 subj=unconfined_u:system_r:syslogd_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:var_t:s0 tty=(none) uid=0
Are you sure you do not have a configuration problem. This AVC indicates that syslog-ng is trying to create a file/directory under /var. As opposed to under /var/log.
(In reply to comment #1) > Are you sure you do not have a configuration problem. This did occur to me, and I looked at the syslog-ng configuration for clues. I didn't tweak anything from the default package, although I did have to disable (and remove) the previous syslog mechanism when I did the upgrade. It is possible there is something odd there. The config file (/etc/syslog-ng/syslog-ng.conf) only refers to /var/log/$FOO paths. > This AVC indicates that > syslog-ng is trying to create a file/directory under /var. As opposed to under > /var/log. Agreed, it does seem to be doing that and for no reason I can discern. Is this actually a potential bug with syslog-ng? Or it just might be something that happens on upgrade v. a fresh install? I set enforcing to Permissive and restarted syslog-ng, while running 'watch -d ls -l /var'. I saw that syslog-ng created (successfully this time) this file: -rw------- 1 root root 41 2008-01-28 08:50 syslog-ng.persist With the contents of: SLP1affile_sd_curpos(/proc/kmsg) The file seems to be written on service stop. What is interesting is stopping the service creates an AVC denial, but nothing is logged about the denial because the service is stopped (setroubleshoot issues an alert, though, and captures the same details.) Is this a file that holds persistence information for the logger between restarts? Anyway, not sure if this is an error (config?) for syslog-ng or something the policy should allow.
restorecon -R -v /var/log should fix this.
restorecon doesn't fix it. I just tried it again, doing a syslog-ng restart then restorecon then another syslog-ng restart; same error both times, except it was trying to write a file this time (see below). Policy version here is selinux-policy-3.0.8-84.fc8. I'll update to the latest (-89) and try it again. If it doesn't fix the behavior, I'll reopen this bug. avc: denied { write } for comm=syslog-ng dev=dm-0 name=syslog-ng.persist pid=2018 scontext=system_u:system_r:syslogd_t:s0 tclass=file tcontext=unconfined_u:object_r:var_t:s0
Ok it am not familiar with syslog-ng.persist, never seen it before. What directory is this in? We probably need a context for this file/directory.
It appears at /var/syslog-ng.persist. It's a binary file. Here is what it looked like when it was able to write, i.e., permissive mode: -rw------- root root unconfined_u:object_r:var_t /var/syslog-ng.persist /usr/bin/file /var/syslog-ng.persist /var/syslog-ng.persist: writable, regular file, no read permission The package is owned by 'silfreed' (Douglas Warner), who I just added to the Cc: to this bug. I don't know who knows what syslog-ng is needing to do with syslog-ng.persist, such as why it has to put the file in /var instead of e.g. /var/log.
This bug seems to be related/duplicate of bug#374051 for F-7. I was just getting started understanding what was going on here and trying to figure out how to write an selinux policy to fix it, but it seems you've found the real cause - the syslog-ng.persist file shouldn't be under /var. I plan on moving this to /var/state/syslog-ng/syslog-ng.persist. Would the current policies support this or would we still need to add a new context?
How about /var/lib/syslog-ng/syslog-ng.persist Then we can label this directory syslog_var_lib_t
Okay; it looks like /var/state might be a directory that was used many releases ago and has been deprecated. /var/lib/syslog-ng sounds good to me; I'll update my specs shortly. Will this policy update go into F-7 when it's ready as well? Should I create a duplicate bug for F-7 for selinux-policy (and I would create an F-8 bug for syslog-ng to depend on this)?
I dropped the ball on this one. Fixed in selinux-policy-3.0.8-102.fc8
I tested this against 3.0.8, I seem to recall it had one more occurrence, then no more. Looks like that was 09 May, so I must have loaded policy, rebooted, but perhaps a relabel needed to be done. Haven't seen the error since then. Currently running selinux-policy-3.0.8-113.fc8 working fine. Closing as fixed, thanks.