Installing bind is not very clear for me

[/dev/rob0]

On Fri, Sep 04, 2015 at 05:27:18PM +0000, Mike Hoskins (michoski) 
   wrote:
> 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> wrote:
> 
> >On Thu, Sep 03, 2015 at 11:02:23PM +0200, Reindl Harald wrote:
> >> Am 03.09.2015 um 22:59 schrieb Robert Moskowitz:

> >> >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.  :-)

In most cases of "understanding firewall config" the best answer is 
to TURN OFF such misfeatures as DNS filtering.  It's shameful that 
such horrible misfeatures are marketed toward people who don't know 
better.

Sorry, not wishing to put you on the spot as a Cisco person (I really 
do appreciate your contributions here, BTW), but some of the Cisco 
"fixup" features are really bad.  "SMTP Fixup" has a long history of
being pilloried on the Postfix list.

> >> 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.

A point I tried to make there is that while many distributors by 
default use "named -u <user>" in their packages, it's not all of 
them, and many of us (for many reasons) stick with source straight 
from ISC.

I still have a server which is not using named -u, but I am not 
losing any sleep over that.  And I don't use chroot at all.

> 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.

I am not advocating running as root as a best practice; I agree, 
you're better off with "-u user".  But for small-time players and 
beginners, it's not that big a deal.  They should focus on bigger 
problems.

> >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
> >any kind?
> >
> >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.

Okay, conceded.  You definitely win on that one. :)

However, from what I understand, we're unlikely to see compromises
in named, because it will ASSERT and crash before that point.  Offer
void where taxed or prohibited, or where attackers have outsmarted
and acted before the BIND9 developers. :)
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: