resolvconf: support Debian's broken resolvconf

[zx2c4]

This patch is untested, and won't really be easily testable until
EggieCode/wireguard-ppa#20 is merged and uploaded. However, without
testing, several observations struck me:

• resolvconf doesn't need real interface names. A bogus name will work
  just fine.
• Prefixing an arbitrary name with 'tun' moves it to the top-ish of the
  list.
• Debian's resolvconf ignores arguments after the first, so we can still
  continue to supply the openresolv flags for implementations that
  support it.

Thus, we give resolvconf tun.%i, and this should work good enough. There
are a few limitations, however:

• The DNS server is not exclusive, which means that if it doesn't
  reply in time, the resolver might choose to try other servers. This is
  a security feature limitation of Debian's resolvconf. Not our problem,
  perhaps?
• This doesn't handle anything with the convoluted --enable-updates/
  disable-updates logic, which may or may not be in use, in which case,
  who knows what to do.
• Building on that last point, I'm still uncertain exactly how Ubuntu's
  use of dnsmasq interacts with --enable-updates/disable-updates and
  resolvconf in general.

So, all and all this might be a bug-fix improvement over before, but
still not perfect. Incremental baby steps.

Signed-off-by: Jason A. Donenfeld Jason@zx2c4.com

[zx2c4]

Looks like EggieCode/wireguard-ppa#20 has been merged.
@cpu Could you test this trick out in various configurations?

[zx2c4]

https://git.zx2c4.com/WireGuard/commit/?id=1d7fd68f039fd90a2bfa935324b6b57e024827fa

[EggieCode]

Tested the on ubuntu zesty, works!
https://gist.github.com/EggieCode/29ec9019e0acbb948ddc8165e33b4cc0

[cpu]

The DNS server is not exclusive, which means that if it doesn't reply in time, the resolver might choose to try other servers. This is a security feature limitation of Debian's resolvconf. Not our problem, perhaps?

Ultimately if the Debian resolvconf doesn't have a way to support an exclusive DNS server I think our hands are tied. We can document this and revisit when there are better options.

This doesn't handle anything with the convoluted --enable-updates/ disable-updates logic, which may or may not be in use, in which case, who knows what to do.

@zx2c4 Can you expand on what --enable-updates is or point to some docs? I'm not groking this part or what logic you're referring to.

Overall seems like the least bad approach in a sea of bad choices. It's unfortunate that the one resolvconf package can't be used in a leak-resistant manner and the other can't be used reliably as a drop-in and has its own warts. :-/

I'm trying this PR in a few environments and will merge when those complete. Thanks!

[cpu]

Worked as advertised on the 16.04 hosts I tested.

[zx2c4]

@cpu wrote:

Ultimately if the Debian resolvconf doesn't have a way to support an exclusive DNS server I think our hands are tied. We can document this and revisit when there are better options.

Well, there's this insanity:

# echo nameserver 8.8.8.8 > /etc/resolv.conf.wg0-exclusive
# mount --bind -o ro /etc/resolv.conf.wg0-exclusive /etc/resolv.conf
# rm -f /etc/resolv.conf.wg0-exclusive

That will make it exclusive and prevent anything from overwriting it. When you're done, you run umount /etc/resolv.conf. This is a slightly insane hack though. I'd recommend just merging this PR as is and revisiting such dark incantations later.

---

@cpu wrote:

Can you expand on what --enable-updates is or point to some docs? I'm not groking this part or what logic you're referring to.

http://manpages.ubuntu.com/manpages/zesty/man8/resolvconf.8.html

       With -a, -d or -u:
              if  updating  is  not  enabled,  schedule a delayed update.  The
              delayed update will be carried out when updates are enabled.

       --enable-updates
              Set the  flag  indicating  that  resolvconf  should  run  update
              scripts  when  invoked  in  the  future with -a, -d or -u.  If a
              delayed update was scheduled then run update scripts.

       --disable-updates
              Clear the flag.

       --updates-are-enabled
              Return 0 if the flag is set, otherwise return 1.

One way of dealing with this would be to just call --enable-updates explicitly, but then you don't have compatibility with resolvconf, and the "oneliner" gets awfully complicated. But I'm not convinced this actually breaks anybody's non-custom-and-strange setup. So I think this PR can be merged as-is, and we'll all mostly benefit.

If you're especially paranoid, just recursively download the entire Ubuntu source package tree, untar everything, and grep for resolvconf .*-d or resolvconf .*--disable-updates. Hopefully nothing serious uses it, or hopefully things that do use it very quickly after run the --enable-updates switch.

---

@cpu wrote:

Worked as advertised on the 16.04 hosts I tested.

Did you test this on a fresh Ubuntu desktop host? That might be the setup to evaluate, since it probably has the largest quantity of nausea.

[jlund]

Did you test this on a fresh Ubuntu desktop host? That might be the setup to evaluate, since it probably has the largest quantity of nausea.

Ha!

I just tested this on a desktop installation of Ubuntu 16.04 and it works perfectly. The tun prefix is a clever workaround that amounts to a huge improvement for Debian resolvconf users while still maintaining compatibility with other distros.

It's hard not to smile while reading the "insane hack", but the good news is that I was unable to trigger any DNS leaks in my testing. We can probably avoid the dark incantations for now.

Thank you!

[zx2c4]

I wrote several months ago:

I'd recommend just merging this PR as is and revisiting such dark incantations later.

It is nearly Halloween and I am thus revisiting these dark incantations: https://lists.zx2c4.com/pipermail/wireguard/2017-October/001826.html

Any opinons from the Stresiand-side of things?

[cpu]

@zx2c4 Thanks for tagging us with the discussion (And for another foray into the darker regions of the Linux desktop ecosystem 🔮 👻 🔮 )

I find the hatchet somewhat unpleasant but that's not a point of disagreement with anyone. I don't have strong opinions whether or not it be used. It seems like if systemd/systemd#7202 were adopted the best bet for Streisand Ubuntu WireGuard clients would be to use systemd-resolver and I'd be happy to push folks that way instead of dark /etc/resolv.conf magic.

I guess that's a longer way of saying that I'm going to punt to the maintainers of the Ubuntu/Debian packages here while I watch 7202.