Bug 2196699
| Summary: | Missing TLS CA certificates in chroot instance prevent DoT forwarding with remote-hostname verification | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stew <stewart_whitman> |
| Component: | bind9-next | Assignee: | Petr Menšík <pemensik> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 38 | CC: | dns-sig, pemensik, pspacek |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | bind9-next-9.19.13-1.fc38 bind9-next-9.19.13-1.fc37 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-05-28 01:03:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Can be fixed by: mkdir -p /var/named/chroot/etc/pki/tls adding /etc/pki/tls/cert.pem into /etc/named-chroot.files mount follows symlink target, so it works even with symlink in place. I wouldn't recommend running named-chroot.service if SELinux is in enforcing mode. It provides better protection without weird configurations of chroot. But sure, this should be fixed. When checking strace of chrooted named process, I have noticed the OpenSSL is trying to access non-existent files. # grep /etc/pki named.strace openat(AT_FDCWD, "/etc/pki/tls/cert.pem", O_RDONLY) = 6 newfstatat(AT_FDCWD, "/etc/pki/tls/certs/c06d5c68.0", 0x7ffed34487a0, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/etc/pki/tls/certs", 0x7ffed3448610, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/etc/pki/tls/certs/c06d5c68.0", 0x7ffed34487a0, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/etc/pki/tls/certs", 0x7ffed3448610, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/etc/pki/tls/certs/c06d5c68.0", 0x7ffed34487a0, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/etc/pki/tls/certs", 0x7ffed3448610, 0) = -1 ENOENT (No such file or directory) /etc/pki/tls/certs certainly does not contain any hashed entries (on f39 rawhide). There is better directory to contain such entries: /etc/pki/ca-trust/extracted/pem/directory-hash/ But that is not even tried. Not sure this is a problem of OpenSSL default configuration or named build configuration. Should be investingated, whether there is possible optimization. Prepared testing change: https://src.fedoraproject.org/rpms/bind9-next/pull-request/2 Filled bug #2203478 to report issues from comment #2. (In reply to Petr Menšík from comment #1) > I wouldn't recommend running named-chroot.service if SELinux is in enforcing > mode. It provides better protection without weird configurations of chroot. > But sure, this should be fixed. Yeah, you make a great point. I've been pretty much on "chroot auto-pilot" since about Fedora 5 (and before on Solaris/SunOS) - not even considering the cage vs. selinux detect trade-off. I will change. I'm just so happy that bind9-next will allow me to get rid of all the stubby/stunnel dns patchwork. Thanks! FEDORA-2023-ee14becc92 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ee14becc92 FEDORA-2023-f46d9ddec4 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f46d9ddec4 FEDORA-2023-ee14becc92 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ee14becc92` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ee14becc92 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-f46d9ddec4 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f46d9ddec4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f46d9ddec4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-ee14becc92 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2023-f46d9ddec4 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report. |
When running a forwarding DNS server, Fedora 38 version of bind 9.19.11 (bind9-next-chroot-9.19.11-1.fc38.x86_64), using DoT and TLS certificate verification - i.e. with a remote-hostname specified - queries to a non-chroot instance with TLS certificate validation work whereas queries to a chroot instance fail with error "TLS peer certificate verification failed". I suspect this is because the Root? TLS CA certificates are not made available (not listed in /etc/named-chroot.files) to the chroot environment in /var/named/chroot. I'm assuming remote-hostname verification should 'just work' in either instance. Or at least, the result should be the same between chroot and non-chroot. Reproducible: Always Steps to Reproduce: 1. Construct a forwarding name server instance using DoT to forward and specifying a TLS with named.conf: ... forwarders port 853 tls google-DoT { 8.8.8.8; 8.8.4.4; }; /* Google DNS-over-tls */ ... 2. Add the tls entry specification in named.conf, including 'remote-hostname' so that the TLS chain must be examined: tls google-DoT { remote-hostname "dns.google"; }; 3. Start the forwarding name server: systemctl start named-chroot 4. Turn on query logging: rndc querylog on 5. Do a host lookup using the name server: nslookup www.isc.org 127.0.0.1 and get: Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find www.isc.org: SERVFAIL 6. Observe in TLS peer certificate verification error from query log: named[8522]: client @0x7fc7c8099000 127.0.0.1#51508 (www.isc.org): query failed (TLS peer certificate verification failed) for www.isc.org/IN/A at ../../../lib/ns/query.c:7723 7. Stop named-chroot: systemctl stop named-chroot 8. Start non-chroot name server: systemctl start named And repeat nslookup in 5, and observe a good response. 10. Stop named: systemctl stop named 11. Comment out remote-hostname from tls entry specification: tls google-DoT { //remote-hostname "dns.google"; }; restart named-chroot: systemctl start named-chroot and verify that lookup succeeds. Actual Results: Chroot name server fails. Non-chroot name server succeeds. Expected Results: Identical results from chroot/non-chroot name servers. I also tried explicitly using the TLS CA certificates - that is, copying the default pem bundle to /etc/named and specifying the ca-file explicitly, i.e.: cp /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/named And then using: tls google-DoT { ca-file "/etc/named/tls-ca-bundle.pem"; // Workaround remote-hostname "dns.google"; }; and then using the chroot server, and this worked. N.B.: I think openssl's default file is /etc/pki/tls/cert.pem which is symbolically linked to the file /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.