Bug 141571 - named logs in /var/named are considered zone files, append denied
named logs in /var/named are considered zone files, append denied
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-02 01:33 EST by Sven
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-08 12:08:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sven 2004-12-02 01:33:29 EST
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 10:47:27 EST
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 14:19:31 EST
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 12:08:37 EST
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 12:24:58 EST
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.

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