Installing bind is not very clear for me
Mike Hoskins (michoski)
michoski at cisco.com
Fri Sep 4 17:27:18 UTC 2015
On 9/4/15, 1:12 PM, "bind-users-bounces at lists.isc.org on behalf of
/dev/rob0" <bind-users-bounces at lists.isc.org on behalf of rob0 at gmx.co.uk>
>On Thu, Sep 03, 2015 at 11:02:23PM +0200, Reindl Harald wrote:
>> Am 03.09.2015 um 22:59 schrieb Robert Moskowitz:
>> >On 09/03/2015 04:35 PM, Leandro wrote:
>> >>Ok ...
>> >>I got BIND 9.10.2-P3 working.
>> >>I compiled with
>> >>./configure --with-openssl --enable-threads --with-libxml2
>> >>make install
>> >>Json statistics channel is working and chroot is not longer
>> >But do make sure you have selinux enforced. Or run behind
>> >multiple firewalls...
>> behind *multiple firewalls* - ?!?! - oh come on and get serious
>> instead promote snakeoil -
>I quite agree here. Firewalls that attempt to filter DNS have
>terrible reputations for *breaking* DNS. A single firewall is bad
>enough; multiple firewalls sounds like a disaster.
True, have fixed many of those over the years, though in fairness this is
often a matter of expecting to run a firewall (or anything) "out of box"
without understanding the config. If that's the stance of the admin, you
likely have a lot more to worry about security-wise than named chroot. :-)
>> typically BIND is *not* running as root and hence does not need
>> any special handling compared to any other network service
>I don't know if we can say what is "typical". We can say, for
>running on Linux at least, that running as root is safe. A
>compromised named would get root after having dropped superuser
>privileges, so it wouldn't be able to do much.
I probably misunderstand your response or am reading too much into the
wording. Named doesn't run as root due to -u giving up permissions. That
combined with the fact chroot itself has known shortcomings is why it's
fallen out of BCP amongst name server operators. It's not that anyone
suggests the alternative to chroot is to just run as root. You are still
running as a non-privileged user post-startup, and permissioning things
appropriately to minimize damage in the event of a compromise.
>Regardless, again I quite agree that special handling is not
>necessary. Look at the various BIND9 security announcements over
>the years. When have you seen one which involved a compromise of
>I cannot say with authority that BIND9 has never had a compromise,
>but I am confident in saying I have never seen one.
I appreciate the viewpoint, and I can even agree with it, but the past is
not necessarily a key to the future. The reality is none of the nastiest
0-days were ever expected. As a security professional you try to insulate
against potential risks, not just things you have already observed. It's
up to each operator to determine appropriate cost/benefit, and this is not
an argument for chroot, but I do caution against an "I've never seen it
before so wouldn't worry about it" stance on security.
More information about the bind-users