strongswan ipsec status issue with apparmor

[Douglas Kosovic]

[Impact]

 * Certain strongswan based vpn setups fail, especially those based on
   network-manager-l2tp or neutron-vpn-netns-wrapper

 * The fix is opening up the apparmor profile slightly for charon and
   stroke where paths are disconnected

[Test Case]

 * valid VPN setup with network-manager-l2tp, then running "sudo ipsec status"

 or

 * valid neutron-vpn setup and then
    # mkdir /tmp/test
    # ip netns add testns
    # ip netns exec testns neutron-vpn-netns-wrapper --mount_paths "/var/run:/tmp/test" --cmd "ipsec,status"

  In both cases the command fails as it can't reach charon log.

[Regression Potential]

 * Since the profile for strongswan is opened up a bit (and not more
   restricted) the regression potential for strongswan should be minimal.

 * Yet OTOH due to the change there is a slightly higher security risk
   now. That said the case seems to be exactly what the feature was
   designed for [1] and there are several other packages holding a similar
   flag.

  [1]: http://wiki.apparmor.net/index.php/ReleaseNotes_2_5#path_name_lookup_and_mediation_of

[Other Info]

 * The part of the "valid VPN setup" both Test cases would need some more
   input by the reporters if possible - to easen testing (see comments
   #5+#6 and #28+#29 for the current status on tests).

 * Unless this is done we have to rely more than usual on the reporters to
   verify this.

$ lsb_release -rd
Description: Ubuntu 16.04 LTS
Release: 16.04

$ apt-cache policy strongswan
strongswan:
  Installed: 5.3.5-1ubuntu3
  Candidate: 5.3.5-1ubuntu3
  Version table:
 *** 5.3.5-1ubuntu3 500
        500 http://au.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        500 http://au.archive.ubuntu.com/ubuntu xenial/main i386 Packages
        100 /var/lib/dpkg/status

Looks like 'ipsec status' might be causing strongswan's charon to write to run/systemd/journal/dev-log instead of /run/systemd/journal/dev-log and apparmor doesn't like it.

Extract from /etc/apparmor.d/abstractions/base :
  /{,var/}run/systemd/journal/dev-log w,

With an established ipsec connection, issue the following :

$ sudo ipsec status
connecting to 'unix:///var/run/charon.ctl' failed: Permission denied
failed to connect to stroke socket 'unix:///var/run/charon.ctl'

$ journalctl
...
Jun 01 12:15:07 ThinkCentre-M900 kernel: audit: type=1400 audit(1464785297.366:491): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="/usr/lib/ipsec/charon" name="run/systemd/journal/dev-log" pid=4994 comm="charon" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
...

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: strongswan 5.3.5-1ubuntu3
ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jun 1 23:06:53 2016
InstallationDate: Installed on 2016-05-11 (21 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
PackageArchitecture: all
SourcePackage: strongswan
UpgradeStatus: No upgrade log present (probably fresh install)

[Simon Déziel (sdeziel)]

Hi Douglas,

I'm unable to reproduce this on a Xenial host. Are you running in a container or something similar? Also, have you altered the strongswan systemd unit?

[Douglas Kosovic (dkosovic)]

Hi Simon,

UEFI Lenovo desktop PC is what I'm running Xenial on.

I'm the new maintainer for network-manager-l2tp VPN plugin for NetworkManger :
   https://github.com/nm-l2tp/network-manager-l2tp

I started an IPSec/L2TP connection using network-manager-l2tp before issuing the 'sudo ipsec status'. So it may be something with network-manager-l2tp IPSec connections that triggers the issue.

I've encountered a few scenarios with strongswan and network-manager-l2tp where an IPSec connection hasn't been established yet, and was hoping to check the connection status in the code by invoking 'ipsec status {connection name}', before it tries to do a L2TP connection.

Tommorow I'll try and do a bit more testing on other Xenial installs and maybe try an IPSec connection without network-manager-l2tp on the PC with the issue to see if I can reproduce. Will get back to you.

[Simon Déziel (sdeziel)]

On 2016-06-01 10:24 AM, Douglas Kosovic wrote:
> UEFI Lenovo desktop PC is what I'm running Xenial on.

OK.

> I'm the new maintainer for network-manager-l2tp VPN plugin for NetworkManger :
> https://github.com/nm-l2tp/network-manager-l2tp

Oh nice!

> I started an IPSec/L2TP connection using network-manager-l2tp before
> issuing the 'sudo ipsec status'. So it may be something with network-
> manager-l2tp IPSec connections that triggers the issue.
>
>
> I've encountered a few scenarios with strongswan and network-manager-l2tp where an IPSec connection hasn't been established yet, and was hoping to check the connection status in the code by invoking 'ipsec status {connection name}', before it tries to do a L2TP connection.
>
> Tommorow I'll try and do a bit more testing on other Xenial installs and
> maybe try an IPSec connection without network-manager-l2tp on the PC
> with the issue to see if I can reproduce. Will get back to you.

Yes, that's what I was about to ask. Thanks.

[Douglas Kosovic (dkosovic)]

Doesn't appear to matter if bare metal PC or VM.

So far haven't been able to reproduce 'ipsec status' issue other than using network-manager-l2tp, but need to do more comprehensive command-line tests that mimics better what network-manager-l2tp is doing.

[Douglas Kosovic (dkosovic)]

I wasn't able to reproduce issue from the command-line with NetworkManager-l2tp, it only happens after NetworkManager-l2tp restarts strongSwan under NetworkManager.

Turns out it is the same NetworkManager issue as the following :
   https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1244157/comments/7

I used the attached patch for :
    /etc/apparmor.d/usr.lib.ipsec.charon
    /etc/apparmor.d/usr.lib.ipsec.stroke

[Douglas Kosovic (dkosovic)]

Somehow forgot the attachment, find attached.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "/etc/apparmor.d/usr.lib.ipsec.* patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Simon Déziel (sdeziel)]

Hi Douglas, thanks for digging this down and providing a patch. The 2 profiles don't ship with any flags so you probably added "complain" before generating your diff.

[Douglas Kosovic (dkosovic)]

Sorry, you are correct, I had forgotten I had changed to "complain" a while back for the two profiles to help with debugging.

On a clean Ubuntu 16.04 install, I can confirm with just flags=(attach_disconnected) for the two profiles, things work as expected.

[Robie Basak (racb)]

Thanks to Simon and Douglas from figuring this out. Based on your comments I think this bug should be marked Invalid then?

[Simon Déziel (sdeziel)]

Based on Douglas' last comment, I believe that the 2 Strongswan profiles are missing the "flags=(attach_disconnected)" to make NetworkManager-l2tp happy. The first patch needs a little cleanup but the bug is valid IMHO.

[Robie Basak (racb)]

Thanks Simon. Sorry I misunderstood.

[Trent Lloyd (lathiat)]

This also effects Neutron VPNaaS (neutron-vpn-agent) - preventing VPNaaS from working with strongswan on Xenial. flags=(attach_disconnected) on /usr/lib/ipsec/stroke appears to resolve the issue.

[Christian Ehrhardt  (paelzer)]

Douglas, Simon thanks for your great work on this already.
I'll try to look at integrating this on the coming (might take a bit still) merge of strongswan.

[Christian Ehrhardt  (paelzer)]

FYI - A merge of latest Debian plus this fix on top is currently in the review queue for Zesty.

[Aquib Mir (aquibmir)]

Hello guys, I am new to Ubuntu and have landed here after doing some search for the problems I'm having with my VPN.

I gather that there is a patch attached to this thread, how am I supposed to install/apply it?

I am running 16.10 on a Toshiba L750D. Let me know if any other info is required.

Thanks.

[Aquib Mir (aquibmir)]

And this is the error I'm getting when trying to connect to my VPN:

Nov 19 17:49:48 aqm-Satellite-L750 kernel: [34630.268103] audit: type=1400 audit(1479595788.404:535): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/lib/ipsec/charon" name="run/systemd/journal/dev-log" pid=8937 comm="charon" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

[Douglas Kosovic (dkosovic)]

If you are using network-manager-l2tp, the Apparmor strongswan issue is listed in the known issues on the Wiki:
  https://github.com/nm-l2tp/network-manager-l2tp/wiki

The patch just puts the AppArmor profiles for charon and stroke into complain mode. The same can be achieved with the following command-lines:

sudo aa-complain /etc/apparmor.d/usr.lib.ipsec.charon

sudo aa-complain /etc/apparmor.d/usr.lib.ipsec.stroke

[Douglas Kosovic (dkosovic)]

Sorry I gave bad advice, Apparmor complain mode won't help, it was the attach_disconnected in the patch which fixes the issue.

Simplest solution without patching is to disable the charon and stroke Apparmor profiles as mentioned on:
  https://github.com/nm-l2tp/network-manager-l2tp/wiki

[Aquib Mir (aquibmir)]

Will disabling the charon and Apparmor profiles still let the VPN work? I
don't fully understand the technicality of this.

Thanks.

On Sun, Nov 20, 2016 at 12:22 AM, Douglas Kosovic <email address hidden> wrote:

> Sorry I gave bad advice, Apparmor complain mode won't help, it was the
> attach_disconnected in the patch which fixes the issue.
>
> Simplest solution without patching is to disable the charon and stroke
> Apparmor profiles as mentioned on:
> https://github.com/nm-l2tp/network-manager-l2tp/wiki
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1587886
>
> Title:
> strongswan ipsec status issue with apparmor
>
> Status in One Hundred Papercuts:
> Triaged
> Status in strongswan package in Ubuntu:
> In Progress
>
> Bug description:
> $ lsb_release -rd
> Description: Ubuntu 16.04 LTS
> Release: 16.04
>
> $ apt-cache policy strongswan
> strongswan:
> Installed: 5.3.5-1ubuntu3
> Candidate: 5.3.5-1ubuntu3
> Version table:
> *** 5.3.5-1ubuntu3 500
> 500 http://au.archive.ubuntu.com/ubuntu xenial/main amd64
> Packages
> 500 http://au.archive.ubuntu.com/ubuntu xenial/main i386
> Packages
> 100 /var/lib/dpkg/status
>
>
> Looks like 'ipsec status' might be causing strongswan's charon to
> write to run/systemd/journal/dev-log instead of /run/systemd/journal
> /dev-log and apparmor doesn't like it.
>
> Extract from /etc/apparmor.d/abstractions/base :
> /{,var/}run/systemd/journal/dev-log w,
>
> With an established ipsec connection, issue the following :
>
> $ sudo ipsec status
> connecting to 'unix:///var/run/charon.ctl' failed: Permission denied
> failed to connect to stroke socket 'unix:///var/run/charon.ctl'
>
>
> $ journalctl
> ...
> Jun 01 12:15:07 ThinkCentre-M900 kernel: audit: type=1400
> audit(1464785297.366:491): apparmor="DENIED" operation="connect"
> info="Failed name lookup - disconnected path" error=-13
> profile="/usr/lib/ipsec/charon" name="run/systemd/journal/dev-log"
> pid=4994 comm="charon" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
> ...
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: strongswan 5.3.5-1ubuntu3
> ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
> Uname: Linux 4.4.0-22-generic x86_64
> NonfreeKernelModules: wl
> ApportVersion: 2.20.1-0ubuntu2.1
> Architecture: amd64
> CurrentDesktop: Unity
> Date: Wed Jun 1 23:06:53 2016
> InstallationDate: Installed on 2016-05-11 (21 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64
> (20160420.1)
> PackageArchitecture: all
> SourcePackage: strongswan
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/hundredpapercuts/+bug/1587886/+subscriptions
>

--
Aquib Mir
c. 647.997.1982

[Douglas Kosovic (dkosovic)]

AppArmor is a Linux kernel security module that allows administrators to restrict programs' capabilities with per-program profiles.

Disabling the charon and stroke Apparmor profiles is just a workaround that removes the restrictions including the issue you having.

The other option is to edit the two profiles with a text editor and add 'flags=(attach_disconnected)'. But you have to be sure you know where it needs to be added.

[Launchpad Janitor (janitor)]

This bug was fixed in the package strongswan - 5.5.1-1ubuntu2

---------------
strongswan (5.5.1-1ubuntu2) zesty; urgency=medium

  * Update Maintainers which was missed while merging 5.5.1-1.

 -- Christian Ehrhardt <email address hidden> Mon, 19 Dec 2016 16:02:40 +0100

[Dr. Jens Harbott (j-harbott)]

This issue still appears when running neutron-vpnaas from Newton UCA on Xenial, is there a chance to fix it for Xenial, too?

[Christian Ehrhardt  (paelzer)]

Hi,
not sure what Neutron picked up - I'll ping one from the Cloud Archive Team.
Does it even have an own strongswan or just that from the Xenial Archive I'd guess?

For Xenial in general an SRU makes sense.

The change itself is as simple as:
https://git.launchpad.net/~paelzer/ubuntu/+source/strongswan/commit/?h=merge-zesty&id=9b3a90368229add8313f8624beee02f5840dbf0e

[Christian Ehrhardt  (paelzer)]

Checked - UCA has no "extra" strongswan backport, so Xenial SRU would help you all.

[Christian Ehrhardt  (paelzer)]

I have all prepared but since I didn't have the case locally recreated I wanted to ask one of you if you could try to pre-verify the fix via the ppa at:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2443/

[Dr. Jens Harbott (j-harbott)]

The packages from the ppa fix the issue for me. In order to reproduce, install neutron-vpn-agent from Newton UCA and run:

# mkdir /tmp/test
# ip netns add testns
# ip netns exec testns neutron-vpn-netns-wrapper --mount_paths "/var/run:/tmp/test" --cmd "ipsec,status"
2017-02-07 18:17:06.729 17492 INFO neutron.common.config [-] Logging enabled!
2017-02-07 18:17:06.730 17492 INFO neutron.common.config [-] /usr/bin/neutron-vpn-netns-wrapper version 9.0.0
Command: ['ipsec', 'status'] Exit code: 0 Stdout: Stderr: connecting to 'unix:///var/run/charon.ctl' failed: Permission denied
failed to connect to stroke socket 'unix:///var/run/charon.ctl'

With fixed package:
# ip netns exec testns neutron-vpn-netns-wrapper --mount_paths "/var/run:/tmp/test" --cmd "ipsec,status"
2017-02-07 18:21:29.119 22248 INFO neutron.common.config [-] Logging enabled!
2017-02-07 18:21:29.120 22248 INFO neutron.common.config [-] /usr/bin/neutron-vpn-netns-wrapper version 9.0.0
Command: ['mount', '--bind', '/tmp/test', '/var/run'] Exit code: 0 Stdout: Stderr: 2017-02-07 18:21:29.126 22248 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /tmp/test has been bind-mounted in /var/run
Command: ['ipsec', 'status'] Exit code: 3 Stdout: Stderr:

[Christian Ehrhardt  (paelzer)]

Thanks rosenboom,
but it seems one needs more than just that.

As just with the following it won't trigger:
1. new Xenial KVM Guest
2. $ apt install strongswan neutron-vpn-netns-wrapper
3. $ ip netns add testns
4. $ ip netns exec testns neutron-vpn-netns-wrapper --mount_paths "/var/run:/tmp/test" --cmd "ipsec,status"
5. sudo ipsec status
Neither 4 nor 5 trigger the issue.

So it really seems to come down to "with an established ipsec connection, issue the following".
So we might need to mix that into the repro.
I tried with all four (ike1psk, ike1cert, ike2psk, ike2cert) modes of [1] but in none of those cases the issue shows up.

I guess some more special setup - that in your cases are set by either neutron-vpn-netns-wrapper (last case) or network-manager-l2tp (original case) setup to trigger it.

When we are doing proposed verification it will be important that you can do the verifications as well.
I'd be even more convinced if we could find a step-by-step solution from a fresh KVM guest or such. Maybe the original reporter would have a few steps cmdline based to set up network-manager-l2tp in a way to trigger.

[1]: https://code.launchpad.net/~paelzer/+git/strongswan-test-wrapper

[Christian Ehrhardt  (paelzer)]

Despite waiting for even better reproduction steps it passed verifications and other regression tests - so it is ok to be at least considered for SRU. Adding the SRU template now.

[Christian Ehrhardt  (paelzer)]

It is in the unapproved queue now, for this case especially please help testing and verifying once it (hopefully) hits proposed.

[Dr. Jens Harbott (j-harbott)]

Hmm, strange, I retried with a new instance too, now after adding the commands that you missed:

# add-apt-repository cloud-archive:newton
# apt update;apt install strongswan neutron-vpn-agent
# mkdir /tmp/test
# ip netns add testns

I can reproduce with the modified command

# ip netns exec testns neutron-vpn-netns-wrapper --mount_paths "/mnt:/tmp/test" --cmd "ipsec,status"
2017-02-08 09:20:15.731 17729 INFO neutron.common.config [-] Logging enabled!
2017-02-08 09:20:15.732 17729 INFO neutron.common.config [-] /usr/bin/neutron-vpn-netns-wrapper version 9.0.0
Command: ['mount', '--bind', '/tmp/test', '/mnt'] Exit code: 0 Stdout: Stderr: 2017-02-08 09:20:15.744 17729 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /tmp/test has been bind-mounted in /mnt
Command: ['ipsec', 'status'] Exit code: 0 Stdout: Stderr: connecting to 'unix:///var/run/charon.ctl' failed: Permission denied
failed to connect to stroke socket 'unix:///var/run/charon.ctl'

and in the systemd journal I get a matching message:

Feb 08 09:20:15 jr-ansi02 audit[17738]: AVC apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="/usr/lib/ipsec/stroke" name="run/charon.ctl" pid=17738 comm="stroke" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

The unwrapped command is indeed doing fine in comparison:

# ipsec status
Security Associations (0 up, 0 connecting):
  none

After adding the flags from your patch into the profile and restarting apparmor, the issue is resolved:

# ip netns exec testns neutron-vpn-netns-wrapper --mount_paths "/mnt:/tmp/test" --cmd "ipsec,status"
2017-02-08 09:24:47.555 17912 INFO neutron.common.config [-] Logging enabled!
2017-02-08 09:24:47.557 17912 INFO neutron.common.config [-] /usr/bin/neutron-vpn-netns-wrapper version 9.0.0
Command: ['mount', '--bind', '/tmp/test', '/mnt'] Exit code: 0 Stdout: Stderr: 2017-02-08 09:24:47.568 17912 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /tmp/test has been bind-mounted in /mnt
Command: ['ipsec', 'status'] Exit code: 0 Stdout: Security Associations (0 up, 0 connecting):
  none

[Christian Ehrhardt  (paelzer)]

On Wed, Feb 8, 2017 at 10:30 AM, Dr. Jens Rosenboom <email address hidden>
wrote:

> The unwrapped command is indeed doing fine in comparison:

Thanks for an extending look on that.
I'd assume that this also is the reason it shows up to begin with.
However the interaction of either neutron-vpn-netns-wrapper
or network-manager-l2tp is in detail - when invoked from there the issue
shows up.
So it is almost safe to assume that this wrapping is part of the reason to
run into it to begin with.

Thanks to extend the test description, once it hits proposed I'd ask you to
verify that (and some time) then and we should be close to a SRU release.

[Brian Murray (brian-murray)]

It looks like this also should be fixed in Yakkety, is that correct?

[Brian Murray (brian-murray)]

Hello Douglas, or anyone else affected,

Accepted strongswan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/strongswan/5.3.5-1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Simon Déziel (sdeziel)]

The simplest way I could think of to reproduce the issue:

1) systemctl edit strongswan
2) Enter the following to use the mount namespace:
[Service]
ProtectSystem=full
3) systemctl restart strongswan
4) Check dmesg for Apparmor denials, there should be none
5) "ipsec status" should list something

Without the update, dmesg is full of denials like in comment 18 and "ipsec status" produces no output.
With the update applied, everything works fine.

[Simon Déziel (sdeziel)]

I didn't try to reproduce the steps mentioned in comments 5-6 and 28-29 but I'm pretty confident that the above steps are equivalent. On another note, I saw no regression with the -proposed version, thanks!

[Christian Ehrhardt  (paelzer)]

Thanks, setting verification done.

[Christian Ehrhardt  (paelzer)]

Brian, you are right - so far on my polling outside of this bug nobody seemed to care.
But the change is rather small, low impact and more or less applies there as well.
Sorry I punted that too easily, fixed and uploaded to the queue for yakkety as strongswan_5.3.5-1ubuntu4.1.

[Douglas Kosovic (dkosovic)]

As far as NetworkManager-l2tp is concerned, I can confirm the strongswan 5.3.5-1ubuntu3.1 xenial-proposed package worked fine for me.

[Brian Murray (brian-murray)]

Hello Douglas, or anyone else affected,

Accepted strongswan into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/strongswan/5.3.5-1ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Jethro Beekman (jethrogb)]

I think I'm running into the same issue, although I'm not using NetworkManager.

I just installed strongswan and configured a VPN manually in /etc/ipsec.conf

I'm getting the following errors when trying to start strongswan 5.3.5-1ubuntu3.1 using systemctl:

Feb 17 14:11:13 skipton systemd[1]: Starting strongSwan IPsec services...
-- Subject: Unit strongswan.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit strongswan.service has begun starting up.
Feb 17 14:11:13 skipton ipsec[7767]: Starting strongSwan 5.3.5 IPsec [starter]...
Feb 17 14:11:13 skipton ipsec_starter[7767]: Starting strongSwan 5.3.5 IPsec [starter]...
Feb 17 14:11:13 skipton systemd[1]: Started strongSwan IPsec services.
-- Subject: Unit strongswan.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit strongswan.service has finished starting up.
--
-- The start-up result is done.
Feb 17 14:11:13 skipton charon[7783]: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-31-generic, x
Feb 17 14:11:13 skipton charon[7783]: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Feb 17 14:11:13 skipton audit[7783]: AVC apparmor="DENIED" operation="mknod" profile="/usr/lib/ipsec/charon" name="/var/run/charon.ctl" pid=7783 comm="charon" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
Feb 17 14:11:13 skipton audit[7783]: AVC apparmor="DENIED" operation="mknod" profile="/usr/lib/ipsec/charon" name="/var/run/charon.pid" pid=7783 comm="charon" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
Feb 17 14:11:13 skipton charon[7783]: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Feb 17 14:11:13 skipton charon[7783]: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Feb 17 14:11:13 skipton charon[7783]: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Feb 17 14:11:13 skipton charon[7783]: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Feb 17 14:11:13 skipton charon[7783]: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Feb 17 14:11:13 skipton charon[7783]: 00[NET] binding socket 'unix:///var/run/charon.ctl' failed: Permission denied
Feb 17 14:11:13 skipton charon[7783]: 00[CFG] creating stroke socket failed
Feb 17 14:11:13 skipton charon[7783]: 00[LIB] loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random no
Feb 17 14:11:13 skipton charon[7783]: 00[LIB] dropped capabilities, running as uid 0, gid 0
Feb 17 14:11:13 skipton charon[7783]: 00[JOB] spawning 16 worker threads
Feb 17 14:11:13 skipton kernel: audit: type=1400 audit(1487369473.293:83): apparmor="DENIED" operation="mknod" profile="/usr/lib/ipsec/charon" name="/var/run/charon.ctl" pid=7783 comm="charon" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
Feb 17 14:11:13 skipton kernel: audit: type=1400 audit(1487369473.293:84): apparmor="DENIED" operation="mknod" profile="/usr/lib/ipsec/charon" name="/var/run/charon.pid" pid=7783 comm="charon" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

[Jethro Beekman (jethrogb)]

Nevermind. Somehow, /var/run was not symlinked to /run on my system. I fixed that and now there's no problem.

[Douglas Kosovic (dkosovic)]

I can confirm NetworkManager-l2tp is working fine with the following yakkety-proposed packages:
  strongswan_5.3.5-1ubuntu4.1_all
  strongswan-charon_5.3.5-1ubuntu4.1_amd64
  strongswan-libcharon_5.3.5-1ubuntu4.1_amd64
  strongswan-starter_5.3.5-1ubuntu4.1_amd64
  libstrongswan_5.3.5-1ubuntu4.1_amd64
  libstrongswan-standard-plugins_5.3.5-1ubuntu4.1_amd64

Only strongswan AppArmor related messages I see are just status messages which are fine :

Feb 18 11:50:32 ubuntu audit[506]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/ipsec/charon" pid=506 comm="apparmor_parser"
Feb 18 11:50:32 ubuntu audit[507]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/ipsec/stroke" pid=507 comm="apparmor_parser"

Having said that, on Yakkety Yak with the stock strongswan_5.3.5-1ubuntu4 packages, (unlike Xenial Xerus) I'm able to establish a VPN connection with NetworkManager-l2tp even though I see lots of the following AppArmor denied messages :

Feb 18 11:43:33 ubuntu audit[4002]: AVC apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/lib/ipsec/charon" name="run/systemd/journal/dev-log" pid=4002 comm="charon" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

But I think strongswan 5.3.5-1ubuntu4.1 is definitely worthwhile to get rid of those AppArmor denied messages.

[Christian Ehrhardt  (paelzer)]

Ok,
I also tested the yakkety case as described in comment #36 - that is really a good way to reproduce with a less complex setup.
ALso thank you all for your participation in testing with the more complex cases.

So for Xenial:
- VPN can be established with the fix
- ipsec status fixed
- Apparmor DENIES fixed
Fo Yakkety
- l2tp case apparmor DENIES fixed (connection itself sometimes worked before)
- ipsec status fixed

And along that no general regression found.
That said setting verification-done.

[Launchpad Janitor (janitor)]

This bug was fixed in the package strongswan - 5.3.5-1ubuntu3.1

---------------
strongswan (5.3.5-1ubuntu3.1) xenial; urgency=medium

  * fix strongswan ipsec status issue with apparmor (LP: #1587886)

 -- Christian Ehrhardt <email address hidden> Tue, 07 Feb 2017 15:25:47 +0100

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for strongswan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package strongswan - 5.3.5-1ubuntu4.1

---------------
strongswan (5.3.5-1ubuntu4.1) yakkety; urgency=medium

  * fix strongswan ipsec status issue with apparmor (LP: #1587886)

 -- Christian Ehrhardt <email address hidden> Fri, 17 Feb 2017 07:43:22 +0100