AppArmor profile prevents DNS Servers from being added to resolv.conf

Thanks for taking the time to report this bug, Sebastian.

I'm adding it to the Ubuntu Server queue; as you mentioned, this is a relatively old issue and IIUC there's been some pushback to implement this. As Christian mentioned in the Debian bug, enabling write access via the apparmor profile by default could be interpreted as a security risk, so we have to take a deeper look into this problem before we proceed.

FWIW, I haven't tried to reproduce this bug locally, but I am setting its status as Triaged because it's pretty clear that the apparmor profile still doesn't allow strongswan to write to /etc/resolv.conf.

Unfortunately, I don't have enough time to work on this right now.

@server-triage-discuss - looks like there may have been some discussion on this when I wasn't around. Did this mean to get dropped? If so, let's set as Won't Fix.

Here is my take on this:

- we have a DEP8 test that creates a strongswan vpn, and I haven't seen this error there
- that tells me that it's only certain configurations that trigger this (confirming what it's said in the bug description)
- should we allow writing to resolv.conf in all cases? That's what we are a bit uncomfortable with. For such specific local configurations, the /etc/apparmor.d/local/ mechanism is a good fit and something the administrator can add
- of course, it might not be easy to reach that conclusion: troubleshooting ipsec vpns is not easy
- if the need to update resolv.conf is something we can easily detect at service startup time, and if it comes from a sane/secure source (like a config file that only root can write to), then one possible change we could make to the package, and which would be a compromise, is to dynamically adapt the profile if that scenario is detected.

The resolve plugin only writes directly to resolv.conf if resolvconf is not available (see https://docs.strongswan.org/docs/5.9/plugins/resolve.html for details).