Allow wireguard to setup DNS using dns-hatchet (bsc#1243148)

[rfrohl]

This is a bit of a contentious change for me and I currently do not find to much time to continue to work on it, but I would like some feedback on one piece:

There is this code piece in wg-quick[0], which I try to work around here:

	printf 'nameserver %s\n' "${DNS[@]}"
		[[ ${#DNS_SEARCH[@]} -eq 0 ]] || printf 'search %s\n' "${DNS_SEARCH[*]}"
		} | unshare -m --propagation shared bash -c "$(cat <<-_EOF
			set -e
			context="\$(stat -c %C /etc/resolv.conf 2>/dev/null)" || unset context
			mount --make-private /dev/shm
			mount -t tmpfs none /dev/shm
			cat > /dev/shm/resolv.conf
			[[ -z \$context || \$context == "?" ]] || chcon "\$context" /dev/shm/resolv.conf 2>/dev/null || true
			mount -o remount,ro /dev/shm
			mount -o bind,ro /dev/shm/resolv.conf /etc/resolv.conf
		_EOF

Currently my only good idea is to dontaudit the chcon change and setup a file transition for /tmp:

fs_tmpfs_filetrans(wireguard_t, net_conf_t, file, "resolv.conf")

Which then should mean that resolv.conf has the correct label after the mount of /dev/shm/resolv.conf to /etc/resolv.conf.

Not sure if there might be a better option or if that solution might be acceptable in the first place ?

[0] https://git.zx2c4.com/wireguard-tools/tree/contrib/dns-hatchet/hatchet.bash#n27

[rfrohl]

condensed the draft a bit further, to make it easier to digest

[zpytela]

No issue with the selinux bits, I rather failed to understand well the wg-quick steps.

[rfrohl]

No issue with the selinux bits, I rather failed to understand well the wg-quick steps.

They look at the label of resolv.conf and try to re-create the label for the /dev/shm copy, then remount the file over /etc/resolv.conf with the correct label. Allowing the system to access the file as expected.

What I did not understand is where this would have ever worked. relabelto and relabelfrom are not something that I found allowed very often.

The main point I was unsure about is that I 'hide' some of the AVCs and therefor deny steps in the script is using. I was unsure if that is an acceptable route to take for something like this.

But it sounds to me like you do not mind that approach, so I will continue with this solution once I have time again.

[zpytela]

We can talk to wg folks to sync the changes. Now I think I understand, it would possibly be more readable if "cp -a" was used instead of working with $context, but the permission would be needed anyway.