Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Fixing wg-quick's DNS= directive with a hatchet
Date: Sat, 28 Oct 2017 16:35:21 +0200	[thread overview]
Message-ID: <87ineze3x2.fsf@fifthhorseman.net> (raw)
In-Reply-To: <CAHmME9r0ji7bE4kzJ6964y8kzt061rUOLFKGfCJbpO19sTOMRw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3735 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2017-10-28 15:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-25 22:43 Jason A. Donenfeld
2017-10-25 23:37 ` Kalin KOZHUHAROV
2017-10-26  0:55   ` Jason A. Donenfeld
2017-10-26  1:32 ` [PATCH] wg-quick: use bind mount for DNS when no openresolv Jason A. Donenfeld
2017-10-26  1:53   ` Kalin KOZHUHAROV
2017-10-26  1:54     ` Jason A. Donenfeld
2017-10-26 13:41   ` [PATCH v2] " Jason A. Donenfeld
2017-10-26  2:54 ` Fixing wg-quick's DNS= directive with a hatchet Eric Light
2017-10-26  3:21   ` Jason A. Donenfeld
2017-10-26 13:11 ` Jason A. Donenfeld
2017-10-26 16:56 ` Joe Doss
2017-10-26 17:24   ` Jason A. Donenfeld
2017-10-26 21:22   ` Jason A. Donenfeld
2017-10-27 10:07     ` Martin Hauke
2017-10-27 13:22       ` Jason A. Donenfeld
2017-10-27 14:47     ` Joe Doss
2017-10-27 14:51       ` Jason A. Donenfeld
2017-10-27 15:02         ` Jason A. Donenfeld
2017-10-27 15:38           ` Joe Doss
2017-10-27 22:04           ` Bruno Wolff III
2017-10-27 15:38         ` Joe Doss
2017-10-27 17:15           ` Jason A. Donenfeld
2017-10-27 17:52             ` Jason A. Donenfeld
2017-10-27 22:06             ` Daniel Kahn Gillmor
2017-10-28  2:24               ` Jason A. Donenfeld
2017-10-28  2:39                 ` Jason A. Donenfeld
2017-10-28 14:35                 ` Daniel Kahn Gillmor [this message]
2017-10-28 17:57                   ` Jason A. Donenfeld
2017-10-29 12:21                     ` Geo Kozey
2017-10-29 17:07                       ` Jason A. Donenfeld
2017-10-30 11:58                       ` Daniel Kahn Gillmor
2017-10-30 12:10                     ` Daniel Kahn Gillmor
2017-10-29 22:06                   ` Jason A. Donenfeld
2017-10-30 12:16                     ` Daniel Kahn Gillmor
2017-10-31 10:49 ` Jason A. Donenfeld
2017-10-26 19:58 Geo Kozey
2017-10-26 21:11 ` Jason A. Donenfeld
2017-10-26 22:01   ` Geo Kozey
2017-10-26 22:19     ` Jason A. Donenfeld
2017-10-26 22:52       ` Geo Kozey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ineze3x2.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=Jason@zx2c4.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).