Bug 430425 - syslog-ng being blocked from write to var_t
Summary: syslog-ng being blocked from write to var_t
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-01-27 22:56 UTC by Karsten Wade
Modified: 2008-09-04 22:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-09-04 22:49:33 UTC

Attachments (Terms of Use)

Description Karsten Wade 2008-01-27 22:56:54 UTC
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):


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,
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
    SELinux is preventing /sbin/syslog-ng (syslogd_t) "write" to <Unknown>

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 #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

Comment 1 Daniel Walsh 2008-01-28 16:37:16 UTC
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

Comment 2 Karsten Wade 2008-01-28 17:08:20 UTC
(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:


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.

Comment 3 Daniel Walsh 2008-02-26 22:11:33 UTC
restorecon -R -v /var/log 

should fix this.

Comment 4 Karsten Wade 2008-03-03 03:51:14 UTC
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

Comment 5 Daniel Walsh 2008-03-03 15:08:02 UTC
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.

Comment 6 Karsten Wade 2008-03-03 17:18:09 UTC
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.

Comment 7 Douglas E. Warner 2008-03-03 17:28:54 UTC
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?

Comment 8 Daniel Walsh 2008-03-03 18:16:12 UTC
How about /var/lib/syslog-ng/syslog-ng.persist

Then we can label this directory syslog_var_lib_t

Comment 9 Douglas E. Warner 2008-03-03 18:31:22 UTC
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)?

Comment 10 Daniel Walsh 2008-05-07 18:10:45 UTC
I dropped the ball on this one.

Fixed in selinux-policy-3.0.8-102.fc8

Comment 11 Karsten Wade 2008-09-04 22:49:33 UTC
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.

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