Bug 173066 - Bind slave zone transfer blocked by permissions (named)
Bind slave zone transfer blocked by permissions (named)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-13 09:26 EST by Tim Malnati
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-13 13:38:08 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 Tim Malnati 2005-11-13 09:26:54 EST
Description of problem:

Bind permissions (chroot) do not allow transfer and update of slave zones. 
/var/named/chroot/var/named is owned by root and named group permissions are not
writable.  This error is probably related to fixes associated with Bugzilla 167682.

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

bind-chroot-9.3.1-14

How reproducible:

Startup of named service produces the following error during attempted transfer
of slave zone:  transfer of '172.in-addr.arpa/IN' from 172.22.22.11#53 failed
while receiving responses: permission denied -also- dumping master file:
tmp-xXdnkDIupZ: open: permission denied

Steps to Reproduce:
1.  Create slave zone in named.conf to known good primary master
2.  (re)start named daemon (/etc/init.d/named (re)start)
3.
  
Actual results:

slave zone is NOT transferred

Expected results:

proper zone transfer

Additional info:

Error corrected by changing ownership of /var/named/chroot/var/named to named. 
Unfortunately, this reintroduces part of the security vulnerability noted in
Bugzilla 167682 where all zone records become vulnerable.  Master zone records
with owner root within this directory is not a good solution either where
dynamic updates will fail (and probably already are with the new permission
structure).

Also, error message is somewhat misleading where one can easily allow one to
think that the transfer failed due to the master server configuration.
Comment 1 Jason Vas Dias 2005-11-13 13:38:08 EST
We provide the $ROOTDIR/var/named/slaves directory for the purpose of zone
file transfers, which has the correct ownership and permissions 
(where $ROOTDIR is set in /etc/sysconfig/named).
To use, change the 'zone "my.zone." IN { ... type slave; file 'my.zone.db'; ...};'
to 'zone "my.zone." IN { ... type slave; file 'slaves/my.zone.db'; ...};' .
This is documented in the Rawhide/FC5 named(8) and named_selinux(8) man-pages,
which I will backport to FC-4 in the next bind release.

Note that use of the bind-chroot environment is made redundant and the 
"security vulnerability" of bug 167682 you refer to is fixed by use of 
SELinux in Enforcing mode, which will not permit named to write any zone
file unless the 'named_write_master_zones' boolean is true, regardless
of the ownership / permissions of the $ROOTDIR/var/named directory.

Note also that if SELinux is not in Enforcing mode or the 
named_write_master_zones boolean is set, and the ROOTDIR/var/named directory
is writable by the named user, then named is open to the "vulnerability".
This is named's default behaviour and it is up to administrators whether to
accept this vulnerability or not . There is no way to "fix" this without coding
named to be unable to write zone files in the $ROOTDIR/var/named directory,
which would be totally unacceptable to the majority of bind administrators. 

There is no formal vulnerability (CVE/CAN #) regarding named being able to
write its zone files.

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