Date: Sat, 15 Apr 2017 10:57:08 +0200 From: Rhialto <rhia...@falu.nl> Message-ID: <20170415085708.gb17...@falu.nl>
| 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.