Bug 125518 - Permissions on /var/named
Permissions on /var/named
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
2
All Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-08 10:06 EDT by Ben Lentz
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-10-26 10:39:34 EDT
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 Ben Lentz 2004-06-08 10:06:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040207 Firefox/0.8

Description of problem:
The permissions on the /var/named directory from the bind package with
Fedora Core 1 & 2 installed with root.named ownership and 750
permissions. This disallows the named daemon (running as the named
user) to write files to this location. 

This breaks things like running a slave server: When a zone transfer
ocours, named will try to write the updated/new zone file in
/var/named and can't the result is "access denied" written to syslog,
which may make some folks think that the zone tranfer is disallowed,
instead of it being a local permissions issue (although the phrasing
of the error message is not a problem with the RPM!).

This breaks other things too, like where rndc stats and rndc dump_db
are not able to write the corresponding log files to the /var/named
directory where they belong.

I would suggest installing this directory mode 770 instead of the
current 750 to resolve this issue. If there is a compelling reason not
to do this, I'd love to be educated.

Version-Release number of selected component (if applicable):
bind-9.2.3-13

How reproducible:
Always

Steps to Reproduce:
1. Install the bind RPM package.
2. Observe the permissions on /var/named with 'ls -ld /var/named'

    

Actual Results:  Permissions show as mode 750

Expected Results:  Permissions show as mode 770

Additional info:
Comment 1 Daniel Walsh 2004-06-08 13:32:24 EDT
Slave files should be put into a subdirectory owned by named.  The
idea is to protect the named config files from a hacker breaking into
named.  THis way they can read but not modify named files.  Slave
files are a special case and need to be put in a subdirectory.

Dan
Comment 2 Ben Lentz 2004-06-08 14:08:03 EDT
How about the situation where zones allow dynamic updates, requiring 
that the named daemon have write permissions to this directory? 
Wouldn't this qualify for another special case? Or rndc dump_db?
Comment 3 Daniel Walsh 2004-06-09 14:28:20 EDT
Both cases should be handled by subdirs.
Comment 4 Ben Lentz 2004-06-09 15:37:33 EDT
The bind RPM from Red Hat 9 used to install /var/named owned by
named.named, mode 755. This gives named (the daemon) write access to
named (the directory) from the onset. I thought the idea was that
folks concerned about a compromised named daemon would utilize
bind-chroot.

Basically, it used to work out-of-the-box, and it doesn't any more.
Maybe this change was made in the name of security, but it smelled an
awful lot like a bug to me. This seems a lot like installing the
apache RPM with a default DocumentRoot that isn't readable by httpd.

I'm having a tough time believing this is intentional when it looks
broken from my perspective.
Comment 5 Ben Lentz 2004-06-23 16:29:17 EDT
Hello, Just looking for a little validation here. Basically:

bind package from Red Hat 9 installs /var/named as named.named 755.
bind package from Fedora Core 1/2 installs root.root 755.

Is this NOTABUG or am I ASCREWLOOSEBEHINDTHEKEYBOARD?

Thanks for your time, keep up the good work :)
Comment 6 Daniel Walsh 2004-06-23 16:44:40 EDT
/var/named should only be readable by the named process, If you need
slave files you need to create a subdirectory where named has
ownership.  The idea is to protect the contents of the /var/named
directory from expoits of the named program.

Dan
Comment 7 Jason Vas Dias 2004-08-30 18:09:34 EDT
The idea was to overcome known named security vulnerabilites.
Slave zones should be placed in /var/named/slaves.
Dumps & stats files should go into /var/named/data.
If you want to enable dynamic dns, either put the zone files
in a different directory owned by named or change the ownership
of the /var/named directory to named:named - by doing so, you
explictly accept the secuirity risk.
Comment 8 SEKINE Tatsuo 2004-10-26 08:26:28 EDT
Does anyone run BIND as a slave server actually?

After BIND receives the response of AXFR request, BIND try to save it
to temporary file under /var/named (/var/named/chroot/var/named).

Logged messages are below:

Oct 26 21:02:01 x31 named[29304]: running
Oct 26 21:02:01 x31 named[29304]: dumping master file: tmp-XXXXrN9vKS:
open: permission denied
Oct 26 21:02:01 x31 named[29304]: transfer of 'example.co.jp/IN' from
210.xxx.yyy.xxx#53: failed while receiving responses: permission denied

I checked it under the bind-9.2.4-1.
Is this NOTABUG or am I ...?
Comment 9 SEKINE Tatsuo 2004-10-26 09:29:58 EDT
Sorry, but please ignore #8 comment.
I configured named.conf incorrectly.
Comment 10 Jason Vas Dias 2004-10-26 10:39:34 EDT
 Just to knock this bug on the head:
    The zone file directory ($ROOTDIR/var/named) now has ownership
    root:named - this was intentionally to address known security
    vulnerabilities.
    
    If SELinux is enabled, named write access to this directory and
    its files can be granted by setting the SELinux boolean 
    'named_write_master_zones' to 1 :
       # setsebool named_write_master_zones 1

    Otherwise, without SELinux you must set the ownership of the 
    directory to named:named:
       # chown named:named $ROOTDIR/var/named

 I hope this clarifies things.
Comment 11 Ben Lentz 2004-10-26 11:09:29 EDT
Only five months in the works... and all I was looking for was an
explanation. Something like, "The bind package from Fedora Core 1/2
has been changed to support SELinux and now installs root.root 755. If
you don't like this, use 'setsebool named_write_master_zones 1'"

Instead of "You're a jerk and don't know how to use bind- make a new
directory, set the permissions yourself and away you go".

Momma didn't raise no fool, she raised RHCE #809003186608620.

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