Re: bind reacts badly to dhcpcd losing/regaining connectivity

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 15 Apr 2017 10:57:08 +0200
    From:        Rhialto <rhialto%falu.nl@localhost>
    Message-ID:  <20170415085708.GB17890%falu.nl@localhost>

  | Ah, that is probably why the following attempt did not cause bind to
  | open a wildcard socket:
  | 
  |     listen-on-v6 { any; };	/* I had this one already */
  |     listen-on { any; };		/* The next two were new */

For v4, without amending the code to use the "where was this UDP packet
I just received sent to" API, it cannot use a wildcard socket.

The "listen-on" just limits which addresses it binds to (if not "any").  If
you had specific addresses in the v6 clause, you'd have the same permission
problem with it, as then named would also need to bind to specific addresses.

Fixing named v54 (to work the same way as v6) is probably not quite as hard
as I made it sound, the fact that it works for v6 (which uses essentially the
same API, except on a PF_INET6 socket, rather than PF_INET) illustrates
that.

The "automatic-interface-scan" stuff is new to me, and the description
given by reed@ does not correspond with my experiences with this kind of
issue - it all happens too quickly for a (slow) periodic scan to be
the cause - I'd guess that bind is listening to the routing socket and
getting address added/deleted messages, and reacting to those, instantly.

And just for completeness, in case anyone is looking at this thread
sometime later - dhcpcd has nothing whatever to do with the problem,
aside from being the agent that removes dead addresses from down
interfaces, and puts them back later when the interface re-awakens.

kre

ps: Christos - capabilities (if we had them) would not be the answer - if you
were to trust bind to be unhackable, then just using root would be just as
good a solution, if you (wisely) fail to believe that all named's bugs
have been fixed, and that it can still be hacked, then giving it extra
capabilities would still be allowing a privilege escalation - not as big
a one as directly to root perhaps, but big things can often be built on
small steps, and taking over a nameserver's answers (being able to intercept
queries to port 53 and return bogus replies) is one of the standard ways
to launch all kinds of attacks - allowing a hacker to bind to port 53,
and perhaps other priv'd ports, depending upon the granualarity of the perms,
which a capability based solution would essentially do (given named bugs
remain to be exploited) is essentially giving them control of your network.