FS#56684 - [filesystem] 2017.10-2 resolves localhost over network
Attached to Project:
Arch Linux
Opened by Moviuro (Moviuro) - Monday, 11 December 2017, 20:07 GMT
Last edited by Sébastien Luttringer (seblu) - Monday, 17 October 2022, 23:16 GMT
Opened by Moviuro (Moviuro) - Monday, 11 December 2017, 20:07 GMT
Last edited by Sébastien Luttringer (seblu) - Monday, 17 October 2022, 23:16 GMT
|
Details
Description:
filesystem-2017.10-2 wipes /etc/hosts and leaves it empty. Along with /etc/nsswitch.conf ordering `dns` before `myhostname`, using "localhost" as a network identifier makes the system query the DNS server for `localhost.` (over the network) This behavior is undesirable: * It leaks data (you queried localhost at that time) * A malicious DNS server could reply * It could leak more data (curl http://localhost/some/thing) * This setup breaks some tools if the DNS server replies to `localhost.` queries with something else than `127.0.0.1` (e.g. mpc(1) relies on the localhost name rather than 127.0.0.1 to connect to mpd(1)) * It adds latency (wait for DNS response before falling back to `myhostname`) Additional info: * Filesystem 2017.10-2 * No edits made to /etc/hosts or /etc/nsswitch.conf Steps to reproduce: 1 - restore nsswitch.conf and hosts(5) to defaults: # cp /etc/nsswitch.conf /etc/nsswitch.conf.bk # cp /etc/hosts /etc/hosts.bk # tar axf /var/cache/pacman/pkg/filesystem-2017.10-2-x86_64.pkg.tar.xz etc/hosts -O > /etc/hosts # tar axf /var/cache/pacman/pkg/filesystem-2017.10-2-x86_64.pkg.tar.xz etc/nsswitch.conf -O > /etc/nsswitch.conf 2 - run sniffing # tcpdump -tttnei <your if> port domain 3 - try to use 'localhost' % ping -c1 localhost 4 - tcpdump should catch some `A? localhost.` and `AAAA? localhost.` Solutions: There are 2 independant solutions to this issue: 1. change order in nsswitch.conf: `hosts: files mymachines resolve [!UNAVAIL=return] myhostname dns` 2. revert changes from 2017.03-2 to 2017.10-2 made to /etc/hosts (`# tar axf /var/cache/pacman/pkg/filesystem-2017.03-2-x86_64.pkg.tar.xz etc/hosts -O > /etc/hosts`) Choosing one solution is enough to fix the problem. |
This task depends upon
FS#54875Also:
I believe Arch's order of this line is a result of the upstream man page at [1] :
'''
It is recommended to place "myhostname" last in the nsswitch.conf' "hosts:" line to make sure that this mapping is only used as fallback, and that any DNS or /etc/hosts based mapping takes precedence.
'''
This recommendation stems from a very old, pre-v1 commit of systemd, see [2]. In the meantime, we got systemd-resolved, which - if enabled - will internally resolve the same special names as myhostname would [3], explicitly stating:
'''
Lookups for the special hostname "localhost" are never routed to the network. (A few other, special domains are handled the same way.)
'''
Other dns servers, for example "unbound", do the same by default. To protect users that use neither, putting "myhostname" before "dns" is quite the easy fix.
[1] https://www.freedesktop.org/software/systemd/man/nss-myhostname.html
[2] https://github.com/systemd/systemd/blob/ab1ecd3c9a303765f5158a9d4692f6fcbea02540/doc/README.html.in#L116
[3] https://www.freedesktop.org/software/systemd/man/systemd-resolved.html
However, users of systemd-resolved are not impacted by this.
Restore a default localhost into /etc/hosts is not a suitable solution; there is too many lines to add to the job correctly (e.g 127.0.0.53 -> localhost), and nss-myhostname is doing the job fine. So changing the order in nsswitch looks like the best idea.
But, we have implemented bug report
FS#51709, which asked to stick to the default nsswitch.conf. Did you open a bug at systemd to ask them to change their default suggested line in nsswitch.conf ?Note: some resolver don't use nss (and directly read /etc/resolv.conf) which make also important to use a local stub resolver which doesn't resolve local host names and adresses on the network.
https://github.com/systemd/systemd/issues/1280
https://github.com/systemd/systemd/issues/1605
1. to make it work properly, nss-myhostname would have to be split up: the part for localhost. would then be ordered before "dns", but the part for the host's domain (hostname --fqdn) name would come after.
2. systemd-resolved has made nss-myhostname mostly obsolete, it might even be removed eventually.
So I guess the reordering is not a future proof or upstream supported approach.
Might just wanna restore those 2 lines in /etc/hosts for now to fix the default config, worry about the best future approach later.
Until they remove nss-myhostname, it prevents more dns leaks to reorder /etc/nsswitch.conf than just put these 2 addresses back in /etc/hosts. Let's try that one.
hosts: files mymachines resolve [!UNAVAIL=return] myhostname dns
This way, you can be sure that systemd-resolved (which correctly handles localhost and hostname use cases without sending them over the network) is used even for local resolution when it is available, but nss-myhostname is still used before nss-dns if it is not.
As Tarqi mentioned the hostname -d is (none), hostname -f is just the short name this beaks for example my duplicity backup as the source name changed.
I would guess this is not the only pice of software what breaks if there is not an fqdn.
1) Which software are broken?
2) Why the localhost lines in /etc/hosts is better than a stub resolver (see SYNTHETIC RECORDS) as a guidance to users?
2) Not everyone wants to run a local DNS resolver. Since systemd-resolved.service is not enabled by default and no package ships its /etc/resolv.conf symlink, it makes sense to ship a /etc/hosts file with localhost entries so that things are sane by default.
Thus flatpak programs cannot resolve "localhost", leading to all sorts of fun user experiences
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1415
Software, like browsers, which do not use the system resolver on purpose are not valid case studies.
People who do not want stub resolvers on their systems are free to add these lines if this is enough to correct their problem with software that does not respect the NSS APIs.
Our current documentation is misleading, the best practice is to have a stub resolver enabled and not to add some lines from the past in /etc/hosts. I don't think we have anything to correct here.
Yes browsers are broken on various levels, yet they are still a major player within each distribution. If we are to ignore them, which package/project has enough weight to change our minds - flatpak? As outlined, flatpak also refuses to work (does not set "nss-myhostname" in it's nsswitch.conf) and one way to "fix" that is by adding the localhost entries to /etc/hosts.
Checking through "man 5 hosts" it explicitly lists the localhost entries in the EXAMPLES section. So we're sort of going against the official documentation - sure the entries are not mentioned as mandatory yet heavily implied as recommended.
Alternatively perhaps we can look at this from more pragmatic angle: Which takes more time and effort - analysing failures in various projects or reinstating the entries?
I deeply implore you to reconsider and opt for the more pragmatic solution.
I didn't write or think that browsers are broken. Sorry wrong person.
I haven't read much about flatpak issues, but from previous comments there is no problem as nss-myhostname does its job.
The EXAMPLES section of the man pages should show examples, not required things. Also, in the man page you pointed to, the comment is "The following lines are desirable". Desirable is not mandatory. Anyway, the man pages are not official documentation.
Please stay technical with your answers, this is not the place to implore anyone. Use logic and good arguments to convince.