Fixing wg-quick's DNS= directive with a hatchet

[Daniel Kahn Gillmor]

On Sat 2017-10-28 04:24:08 +0200, Jason A. Donenfeld wrote:

> Openresolv is a fine piece of code that works reliably; I'd encourage
> you to check it out, especially before you dismiss the whole idea and
> start recommending dbus instead. It's a tiny component where you can
> see all of its parts as clear transparent components. Many apps can
> interact with it through a consistent mechanism. It doesn't require a
> daemon, nor does it require any central management.

My concern with the resolvconf model (whether implemented by openresolv
or not) is that each daemon that needs to execute resolvconf needs to be
root.

This is because of the extensibility -- you don't know what plugin
scripts you might be invoking when you invoke resolvconf, and those
scripts don't know what your constraints might be.

At its core, this model encourages *anything* that might need to update
/etc/resolv.conf to have full system administration privileges.

Consider a DHCP client (any DHCP client) -- at most, it should have
CAP_NET_ADMIN and maybe CAP_NET_RAW.  And it needs to be able to update
the local DNS resolution, and maybe the hostname.  But it parses
arbitrary data from the network, and acts on it.  yikes!  I'd prefer
that any such daemon run with minimal privileges, but on a system where
resolvconf is present, it has to have superuser privileges, or else
resolvconf won't work.

I actually shipped the resolvconf-admin package in debian to provide
some kind of filtering interface to avoid total garbage from the network
getting accidentally passed through to arbitrary resolvconf plugins.
But it's a setuid program, yuck.

as the package description says:

-------
 Note: setuid binaries like resolvconf-admin are additional attack
 surface on your system.  If you can use a different approach, such as
 enabling systemd-resolved, you should probably prefer it.
 .
 DO NOT INSTALL THIS PACKAGE (or any other with a setuid binary) IF
 YOU DO NOT NEED IT!
-------

We have effective privilege separation in userspace, and it seems
foolhardy not to use it just because some daemon or networking policy
agent needs to update the DNS resolver.

> For this reason, and at Kalin's suggestion as the first reply on the
> thread, I prefix this onto resolv.conf with the hatchet:
>
> # This file was generated by wg-quick(8) for use with
> # the WireGuard interface wg0. It cannot be
> # removed or altered directly. You may remove this file
> # by running `wg-quick down wg0', or if that
> # poses problems, run `umount /etc/resolv.conf'.
>
> Not perfect, of course, but I imagine this simple comment will address
> 85% of confused users very quickly.

You seem to think that 85% of confused users, when faced with the fact
that "the Internet doesn't work" can (a) can determine that their DNS
resolution is specifically what is failing, and (b) subsequently think
to look in /etc/resolv.conf, and (c) follow the instructions therein.
And you think they'll do it all "very quickly".

I say this with love, but I don't think we've worked with the same
caliber of confused users. :) 

> So, based on the above, my intention is to do this, but in the context
> of option (3), which means I'll only warn if there's no resolvconf,
> permitting Debian's resolvconf to provide its limited support if it's
> there and openresolv isn't.

sounds good to me.

> I don't want to manually construct dbus messages from bash.

i understand this complaint, they should offer a simple command-line
tool that communicates the right thing via dbus on the backend.  I've
subscribed to https://github.com/systemd/systemd/issues/7202, thanks for
opening it.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20171028/5932b055/attachment.asc>