Dear Maintainer,

If the VPN one is connecting to wants to add additional DNS servers, charon needs
write access to /etc/resolv.conf. Otherwise we get an error like the following:

  # ipsec up XXX
  [..]
  IKE_SA XXX{X} established between XXX...YYY
  adding DNS server failed
  adding DNS server failed
  handling INTERNAL_IP4_DNS attribute failed
  installing new virtual IP XXX
  [..]

And in dmesg logs:

  audit: type=1400 audit(NNN): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ comm="charon" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
  audit: type=1400 audit(NNN): apparmor="DENIED" operation="unlink" profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ comm="charon" requested_mask="d" denied_mask="d" fsuid=0 ouid=0

Note that the "#include <abstractions/nameservice>" that already exists in charon's profile, is only for *read* access to /etc/resolv.conf, but charon really does need write access.

A patch that worked for me was:
--- /etc/apparmor.d/usr.lib.ipsec.charon	2018-11-30 19:02:12.585715570 -0800
+++ /etc/apparmor.d/usr.lib.ipsec.charon	2018-11-30 18:50:39.850426475 -0800
@@ -68,6 +68,8 @@

   /var/lib/strongswan/*     r,

+  /etc/resolv.conf          w,
+
   # Site-specific additions and overrides. See local/README for details.
   #include <local/usr.lib.ipsec.charon>
 }

X

Hi I thought write should be admin opt-in,
the profile already has
  #include <abstractions/nameservice>
which has
  /etc/resolv.conf        r,

Yes your Deny is a write Deny and that is why you add a "w" rule, but
I thought that should be an explicit admin opt-in for security
reasons. After all changing name resolution is a nice place to start
an attack and opening that (by default) to software that is reachable
from the outside by design might not be too good.

Maybe we could ship a commented out line with some comment what it is
used for and ask users to "put that in your apparmor...local... file
if you want to use ..."

Hi,

another solution would be looking at resolvconf. On my strongSwan setup the
gateway provides DNS and it seems to work just fine here with resolvconf
installed, so it might be worth trying it on your side.

Regards,