bind9 bind 9.14.7

[Kevin]

New Point Version

[Kevin]

​ftp://ftp.isc.org/isc/bind9/cur/9.14/CHANGES

--- 9.14.7 released ---

5299. [security] A flaw in DNSSEC verification when transferring

mirror zones could allow data to be incorrectly marked valid. (CVE-2019-6475) [GL 1252]

5298. [security] Named could assert if a forwarder returned a

referral, rather than resolving the query, when QNAME minimization was enabled. (CVE-2019-6476) [GL 1051]

5297. [bug] Check whether a previous QNAME minimization fetch

is still running before starting a new one; return SERVFAIL and log an error if so. [GL 1191]

5294. [func] Fallback to ACE name on output in locale, which does not

support converting it to unicode. [GL 846]

5293. [bug] On Windows, named crashed upon any attempt to fetch XML

statistics from it. [GL 1245]

5292. [bug] Queue 'rndc nsec3param' requests while signing inline

zone changes. [GL 1205]

[Kevin]

There is a 9.15 branch, but that is "unstable" so I can see why we stay with 9.14

[Douglas R. Reno]

Marking as "high" since it has security fixes

[Bruce Dubbs]

Fixed at revision 22263.

[Kevin]

ok, thanks for that fast update!

Confirmed that building with the --disable-linux-caps removes the error condition.

However, the error persists if not using the argument.

Following note has been added to: ​http://wiki.linuxfromscratch.org/blfs/wiki/bind?version=7

Bind 9.14.5 - 9.14.7 will report the following errors into sys.log, but still runs:

named[459]: listening on IPv4 interface enp0s3, 192.168.56.2#53
named[459]: unable to set effective uid to 0: Operation not permitted
named[459]: generating session key for dynamic DNS
named[459]: unable to set effective uid to 0: Operation not permitted
named[459]: sizing zone task pool based on 2 zones

[Found this link](​​http://bind-users-forum.2342410.n4.nabble.com/BIND-9-14-0-unable-to-set-effective-uid-to-0-Operation-not-permitted-td6844.html) describing named wanting to revert back to UID 0, root for some reason even though it is in chroot at this time.

This page also discusses the issue: ​​https://gitlab.isc.org/isc-projects/bind9/issues/1042

You can disable caps --disable-linux-caps but at the cost of security.

[Bruce Dubbs]

It is not clear to me what the error is. If running in chroot as user named, as best I can tell the only problem is unneeded messages in the log. Unless we can find an upstream fix, I think we do not need to make any changes.

[Douglas R. Reno]

I'm kind of confused on this one... On my systemd system, I have no such messages:

renodr [ /sources ]$ systemctl status named
● named.service - Internet domain name server
   Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-10-17 19:17:24 CDT; 1 day 1h ago
 Main PID: 381 (named)
    Tasks: 10
   Memory: 22.8M
      CPU: 31ms
   CGroup: /system.slice/named.service
           └─381 /usr/sbin/named -f -u named -t /srv/named -c /etc/named.conf

Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:500:2d::d#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:dc3::35#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:500:200::b#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:503:ba3e::2:30#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:7fe::53#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:500:2f::f#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:503:c27::2:30#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:500:2::c#53
Oct 18 19:57:08 POOH named[381]: network unreachable resolving './DNSKEY/IN': 2001:500:a8::e#53
Oct 18 19:57:08 POOH named[381]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)

I'm not sure what it does on SysV though. I don't recall systemd having anything reaching into the capabilities land, but I could be incorrect on that.

On that note, upstream does describe their capabilities code as "suboptimal".

Just to make sure, you do have libcap present and functioning, right? Also, if you rebuild libcap with PAM support (should be unneeded, but suggesting to remove a difference from our configurations), does this problem disappear? I have mine setup as in BLFS (rebuilt with PAM support).

[Kevin]

Have to agree with Bruce that these messages may be nothing more than Warnings from chroot doing its job.
Although, some still received the messages running bind as root or changing the owner of the two files to root:
/srv/named/var/run/named/session.key
/srv/named/var/run/named.pid

The "suboptimal" comments also indicate that ISC working on a better version anyway.
(Sure does not give confidence in using the code)

Further, I have made posts to the mailing list and forums asking for clarification.
Will try PAM, (more complication), to see what happens later tonight.

At this time, it might be good to have a least a "notice" in case others find the error and offer the snippet to disable caps as the only solution if they are finding issues during production or ignore the messages as nothing to see, move along.