On 06/12/2015 11:10 AM, Petr Spacek wrote: > HERE we need to coordinate with other parties who might want to write into the > /etc/resolv.conf file. These include (but might not be limited to): > NetworkManager > initscripts > dhclient > libreswan ? > resolved > connman > > Option is either to implement all the checks and workarounds in all the > projects over and over or to implement all the logic in one place - > dnssec-trigger might be such place. > > Anyone who is going to write to resolv.conf needs to check for captive > portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS > servers and domains. > > *Questions:* > Guys, what are your plans for handling the situations mentioned above? libreswan will not write /etc/resolv.conf is unbound is running. Instead via its _updown script it currently adds the forwarders to unbound and performs the cache flush / requestlist flush. Then it signals NM (which currently then does the same thing - the libreswan specific code can be removed for fedora/rhel when we know the NM version is handling it) > Can we integrate on one place (e.g. by calling into dnssec-trigger) instead > overwriting /etc/resolv.conf independently? If we could have a "hotspot logon network container", which will use its own /etc/resolv.conf and its own disposable DNS, I think the host /etc/resolv.conf could be an immutable 127.0.0.1 entry only. > Second problem: API for applications > ==================================== > (this second step is not part of the F23 feature but it is worth discussing) > Applications and crypto libraries need "an" interface to get DNS data which > are either 100 % correct or declared as not trusted. False positive (trusted) > answers are simply unacceptable because that would allow serious attacks. > > Imagine that OpenSSH client is verifying server's fingerprint against the > value obtained from DNS *instead of asking the user*. If the client accepted a > fake response with faked server's fingerprint then everything is doomed. That is partially solved with a "network logon container". Such a container also resolves the problem of every application immediately connecting to the network when a new network is detected, and all of them hitting the hotspot IP redirect and hitting bad certificates. Firefox is somewhat smart about not reloading its tabs these days, but for instance pidgin is terrible and all my XMPP/jabber servers will throw a TLS warning on the screen. The real fix is for these applications to never experience the "hotspot login" state. > The proposal https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html on > glibc mailing list is to extend getaddr API with flag which says 'secure > answers only'. This will return an answer only if DNSSEC validation for given > answer was successful and the answer was properly signed. > > The assumption here is that something like dnssec-trigger properly configures > local resolver (using the information from DHCP + applying all the necessary > workarounds) to do DNSSEC validation locally so we are 100 % sure that the > fake answer can be detected. > > The open question is how to pass the information about security status to all > the parties. The mechanism needs to be simple so other resolver libraries like > e.g. python-dns can follow the same rules and use the same logic as Glibc. This still seems a largely unsolved/unagreed on problem we have had a lot of discussion about. > Possible states: > a) We are in hot-spot sign-on mode or validating resolver is unavailable for > some reason (early boot, resource constraints, Docker container [finally!], > and so on): > > In this case *nothing* can be trusted. Resolver might return faked answers and > we have no means to check if declared trustworthiness is correct or not. > Again, we need to be 100 % sure from the cryptographical point of view. > > => Application MUST NOT receive any answer marked as "secure"/"trusted" if we > are in this mode. the application shouldn't even be exposed to the world while we are in this mode. The world isn't ready yet for them. Additionally, one could extend this concept and say there is a "DMZ" and "internal" network on the host, and only very selected few applications get onto the DMZ. The hotspot logon is one such app, another one are the VPN apps. For VPN apps, one could leave only the VPN daemons exposed to the external network, and force all applications to only see the world through the VPN. Without a VPN, the host could decide that once hotspot sign happened, to just bridge or move the DMZ into the internal zone. > b) Validating resolver is up, running, properly configured, and the path to > the resolver is trusted - it might be running on localhost or we are in Docker > container and we trust the host and so on. > > In this case we trust to the result of validation indicated by AD bit. > Application will receive the answer marked as trusted if the resolver tells us > to do so by AD bit in the DNS reply. Additionally, these applications could link against a better DNS API, and use something like getdns or edns-query-chain. But I think trusting the AD bit is a good enough solution for most cases, especially with the added mechanism of marking certain DNS servers trusted. Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
