Bug 141571

Summary: named logs in /var/named are considered zone files, append denied
Product: [Fedora] Fedora Reporter: Sven <rhbugzilla>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: jvdias
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-08 17:08:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sven 2004-12-02 06:33:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.3)
Gecko/20040910

Description of problem:
I've got BIND/named logging queries and whatnot into /var/named/*.log,
and selinux assumes the files are zone files, and tries to deny access
to them.
That machine could in theory log to /var/log/named/ or something
instead, but that presumably wouldn't solve the problem if named were
running in a chroot environment below /var/named/.


Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.17.30-2.34

How reproducible:
Always

Steps to Reproduce:
To make named log, I've got the following in my named.conf:

logging {
        channel stuff {
                file "/var/named/named_queries.log" versions 3;
                print-category yes;
                print-severity yes;
                print-time yes;
                };
        channel named_security_log {
                file "/var/named/named_security.log" versions 3;
                print-category yes;
                print-severity yes;
                print-time yes;
                };
        channel named_lameservers_log {
                file "/var/named/named_lameservers.log" versions 3
size 5m;
                print-category yes;
                print-severity yes;
                print-time yes;
                };
        category security {
                named_security_log;
                };
        category queries {
                stuff;
                };
        category xfer-in {
                stuff;
                };
        category xfer-out {
                stuff;
                };
        category notify {
                default_syslog;
                };
        category lame-servers {
                named_lameservers_log;
                };
        };




Actual Results:  Example log message:

kernel: audit(1101614974.070:0): avc:  denied  { append } for 
pid=31271 exe=/usr/sbin/named path=/var/named/named_queries.log
dev=hda7 ino=63003 scontext=root:system_r:named_t
tcontext=system_u:object_r:named_zone_t tclass=file


Expected Results:  presumably, no denial.
poking around the policy sources (for the first time ever, i could be
misinterpreting), named doesn't seem to have a file context for logs,
in the same way that apache or squid do:

/etc/selinux/targeted/src/policy/file_contexts/program/apache.fc:
/var/log/httpd(/.*)?            system_u:object_r:httpd_log_t

/etc/selinux/targeted/src/policy/file_contexts/program/squid.fc
/var/log/squid(/.*)?            system_u:object_r:squid_log_t

perhaps a named rule could allow /var/named/*.log and
/var/named/chroot/var/named/*.log ?

Additional info:

Comment 1 Daniel Walsh 2004-12-02 15:47:27 UTC
It is designed so that those files should go into the data directory.

Try
 channel named_lameservers_log {
                file "/var/named/data/named_lameservers.log" versions 3
size 5m;
                print-category yes;
                print-severity yes;
                print-time yes;
                };

Comment 2 Sven 2004-12-06 19:19:31 UTC
yep, after reconfiguring and restarting, the new log files are now
root:object_r:named_cache_t, and no complaints so far in syslog.

when did this data subdirectory thing happen, because I don't remember
seeing anything about it before..?

Comment 3 Daniel Walsh 2004-12-08 17:08:37 UTC
It happened as a new version in FC3, as a security messure.  Basically
we want to prevent a compromized named from having the ability to
modify the master files.

Comment 4 Jason Vas Dias 2004-12-08 17:24:58 UTC
I think a nice idea would be for the named service script 
( /etc/init.d/named ), on startup to check if SELinux is
enabled AND the named_write_master_zones boolean is enabled;
if so, it will ensure that $ROOTDIR/var/named has the correct
file system permissions to enable write by the named:named user,
setting them to g+w if not. I'll try to get this into the next
release of bind (bind-9.3.0-2 on FC4). 
Then all users would have to do to enable DDNS is enable the boolean
with the GUI.