strongswan (charon) is rejected by apparmor to read /proc/<PID>/fd

Bug #1786250 reported by fermulator on 2018-08-09
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
strongswan (Ubuntu)
Undecided
Unassigned

Bug Description

Used to work fine in Ubuntu 16.04 LTS, and Ubuntu 17.10.

ii strongswan 5.6.2-1ubuntu2 all IPsec VPN solution metapackage

A while ago I upgrade to 18.04 LTS and had consistent issues with strongswan ipsec connectivity VPN.

BASELINE INFO:

$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.15.0-29-generic, x86_64):
  uptime: 13 seconds, since Aug 09 09:27:35 2018
  malloc: sbrk 3268608, mmap 532480, used 1280560, free 1988048
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon test-vectors unbound ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert ipseckey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm ntru bliss curl soup mysql sqlite attr kernel-netlink resolve socket-default connmark farp stroke vici updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp whitelist lookip error-notify certexpire led radattr addrblock unity counters
Listening IP addresses:
  1.0.0.6
  192.168.130.9
  192.168.140.17
  192.168.130.14
  192.168.140.2
  172.17.0.1
  192.168.122.1
Connections:
  <SITE_SNIPPED>primary: %any...<SITE_SNIPPED>primary.<SNIPPED>.com IKEv2, dpddelay=30s
  <SITE_SNIPPED>primary: local: [<USER_SNIPPED>] uses EAP_MSCHAPV2 authentication
  <SITE_SNIPPED>primary: remote: [OU=Domain Control Validated, CN=<SNIPPED>.com] uses public key authentication
  <SITE_SNIPPED>primary: child: 192.168.140.0/24 === 192.168.128.0/17 10.0.0.0/8 172.16.0.0/12 TUNNEL, dpdaction=clear
<SITE_SNIPPED>secondary: %any...<SITE_SNIPPED>secondary.<SNIPPED>.com IKEv2, dpddelay=30s
<SITE_SNIPPED>secondary: local: [<USER_SNIPPED>] uses EAP_MSCHAPV2 authentication
<SITE_SNIPPED>secondary: remote: [OU=Domain Control Validated, CN=<SNIPPED>.com] uses public key authentication
<SITE_SNIPPED>secondary: child: 192.168.130.0/24 === 192.168.128.0/17 10.0.0.0/8 172.16.0.0/12 TUNNEL, dpdaction=clear
Routed Connections:
<SITE_SNIPPED>secondary{2}: ROUTED, TUNNEL, reqid 2
<SITE_SNIPPED>secondary{2}: 192.168.130.0/24 === 10.0.0.0/8 172.16.0.0/12 192.168.128.0/17
  <SITE_SNIPPED>primary{1}: ROUTED, TUNNEL, reqid 1
  <SITE_SNIPPED>primary{1}: 192.168.140.0/24 === 10.0.0.0/8 172.16.0.0/12 192.168.128.0/17
Security Associations (0 up, 0 connecting):
  none

Then we do:

```
 sudo ipsec up <CONNECTION_NAME>

... all the goods happen ...

but near the end:

IKE_SA <CONNECTION_NAME>[1] established between 1.0.0.6[<USER_SNIPPED>]...64.7.137.180[OU=Domain Control Validated, CN=<SNIPPED_HOST>.com]
scheduling reauthentication in 56358s
maximum IKE_SA lifetime 56538s
installing DNS server 192.168.194.20 via resolvconf
installing DNS server 192.168.196.20 via resolvconf
<<HANGS FOREVER>>
```

the DNSes are successfully added to resolvconf (/etc/resolv.conf) - however the resolution doesn't work, and no routes work with the VPN.

After a fresh reboot, this works.
No end of ipsec/strongswan service restarts gets the system out of this "stuck state";

--
Typical workflow (reproduction notes)
 1. fresh boot
 2. VPN connections fine
 3. work work work
 4. disconnect VPN
 5. use system for personal use (or don't)
 6. suspend system overnight
 7. resume system morning
 8. VPN BROKEN as noted above
--

Digging more, I see these errors in dmesg
```
...
[34218.436021] audit: type=1400 audit(1533821247.602:169): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/21179/fd/" pid=21179 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[34368.429799] audit: type=1400 audit(1533821397.596:170): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/22483/fd/" pid=22483 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[34368.437049] audit: type=1400 audit(1533821397.604:171): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/22493/fd/" pid=22493 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[34380.630335] audit: type=1400 audit(1533821409.796:172): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/22656/fd/" pid=22656 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[34395.681889] audit: type=1400 audit(1533821424.847:173): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/22882/fd/" pid=22882 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[34395.688730] audit: type=1400 audit(1533821424.855:174): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/22888/fd/" pid=22888 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
...
```

Does this have anything to do with why the connection is hanging? I have no idea.

Tried this:

$ sudo /etc/init.d/apparmor status
● apparmor.service - AppArmor initialization
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2018-08-09 09:19:09 EDT; 15min ago
     Docs: man:apparmor(7)
           http://wiki.apparmor.net/
  Process: 9518 ExecStop=/etc/init.d/apparmor stop (code=exited, status=0/SUCCESS)
  Process: 14731 ExecStart=/etc/init.d/apparmor start (code=exited, status=0/SUCCESS)
 Main PID: 14731 (code=exited, status=0/SUCCESS)

Aug 09 09:19:06 fermmy systemd[1]: Starting AppArmor initialization...
Aug 09 09:19:06 fermmy apparmor[14731]: * Starting AppArmor profiles
Aug 09 09:19:06 fermmy apparmor[14731]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Aug 09 09:19:06 fermmy apparmor[14731]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Aug 09 09:19:09 fermmy apparmor[14731]: ...done.
Aug 09 09:19:09 fermmy systemd[1]: Started AppArmor initialization.

$ sudo /etc/init.d/apparmor stop
[ ok ] Stopping apparmor (via systemctl): apparmor.service.

REPEAT TEST

 * restart strongswan
 * unroute all connections manually (sudo ipsec unroute <CONNECTION>)

_wtf_, apparmor is STILL rejecting it! (even though it's stopped?)

[34756.774786] audit: type=1400 audit(1533821785.933:177): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/26204/fd/" pid=26204 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

--
NO ACCESS to /proc ;/

$ cd /etc/apparmor.d
$ grep -rins charon * | grep proc
(EMPTY)

--
need to unload charon profile

$ sudo apparmor_parser -R /etc/apparmor.d/usr.lib.ipsec.charon

but STILL, rejecting

[35206.129530] audit: type=1400 audit(1533822235.279:249): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/30951/fd/" pid=30951 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

fermulator (fermulator) wrote :

Also probably worth including the current ipsec.charon profile contents (even though it's disabled now ...)

summary: - strongswan (charon) is rejected by apparmor to read /proc/<PID/fd
+ strongswan (charon) is rejected by apparmor to read /proc/<PID>/fd
fermulator (fermulator) wrote :
fermulator (fermulator) wrote :

while ipsec is still, here are the contents of the /proc/<PID>/fd it's trying to access
```
$ sudo ls -al /proc/3014/fd/
total 0
dr-x------ 2 root root 0 Aug 9 09:51 .
dr-xr-xr-x 9 root root 0 Aug 9 09:51 ..
lr-x------ 1 root root 64 Aug 9 09:51 0 -> 'pipe:[2972727]'
l-wx------ 1 root root 64 Aug 9 09:51 1 -> 'pipe:[2972728]'
lrwx------ 1 root root 64 Aug 9 09:51 10 -> 'socket:[2961426]'
l-wx------ 1 root root 64 Aug 9 09:51 2 -> 'pipe:[2972728]'
```

fermulator (fermulator) wrote :

repeated with more care to ensure profiles are actually unloaded

running this twice, confirms profiles are now not loaded

$ for profile in $(find . | egrep "charon|ipsec" | grep -v local); do sudo apparmor_parser -R /etc/apparmor.d/$profile; done
apparmor_parser: Unable to remove "/usr/lib/ipsec/lookip". Profile doesn't exist
apparmor_parser: Unable to remove "/usr/sbin/charon-systemd". Profile doesn't exist
apparmor_parser: Unable to remove "/usr/lib/ipsec/stroke". Profile doesn't exist
apparmor_parser: Unable to remove "/usr/lib/ipsec/charon". Profile doesn't exist

and, the aa-status confirms
$ sudo aa-status | egrep "ipsec|charon"
(EMPTY)

---

RETRY

 - ffs, connection STILL hangs, but these rejected charon messages in dmesg are no longer happening (so maybe those are a legit bug/issue with the profile to be fixed, but a red-herring to my primary issue)

fermulator (fermulator) wrote :

Submitted a "fork" bug report for the connection hang issue (https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1786261), let this bug report stay for the charon apparmor profile issue.

Hi,
could you add to the apparmor profile of charon this line
   @{PROC}/@{pid}/fd/ r,
Then reload it via:
   sudo apparmor_parser -r /etc/apparmor.d/usr.lib.ipsec.charon

While I never have heard of charon needing this, if the above works you could add it for youself as a config and I could make it part of future packages.

If the above makes those messages disappear but shows new apparmor denies afterwards let me know.

fermulator (fermulator) wrote :

Did this:

```
$ grep include /etc/apparmor.d/usr.lib.ipsec.charon | grep local
  include <local/usr.lib.ipsec.charon>

$ cat /etc/apparmor.d/local/usr.lib.ipsec.charon
# Site-specific additions and overrides for usr.lib.ipsec.charon.
# For more details, please see /etc/apparmor.d/local/README.
#
# https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1786250
@{PROC}/@{pid}/fd/ r,
```

Then reloaded
```
$ sudo apparmor_parser -r /etc/apparmor.d/usr.lib.ipsec.charon
```

Now more complaints in dmesg.

I assume, as you have found completely disabling it before - your'd actual hang isn't gone by that - right?

Changed in strongswan (Ubuntu):
status: New → Triaged
tags: added: server-next

TODO:
add
  @{PROC}/@{pid}/fd/ r,
to the charon apparmor profile

tags: added: bitesize
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers