(mirror of https://github.com/vyos/vyos-strongswan.git) https://git.amelek.net/vyos/vyos-strongswan.git/atom?h=current 2018-09-24T15:59:39+00:00 2018-09-24T15:59:39+00:00 Simon Deziel simon@sdeziel.info 2018-09-20T21:13:12+00:00 urn:sha1:ae0b23db71d7e1298cf0adcf6bf2a0d50c714481 2018-09-24T15:59:39+00:00 Simon Deziel simon@sdeziel.info 2018-09-20T20:58:58+00:00 urn:sha1:912855f3b02f430cbbb77d1f6d5cb44d271ee698 2018-08-07T09:04:17+00:00 Yves-Alexis Perez corsac@debian.org 2018-08-07T09:03:25+00:00 urn:sha1:bd93d36dc8baa6fb3e76d4808278e077d4b47301 Thanks Christian Ehrhardt for the patch closes: #905082 2018-04-27T09:51:04+00:00 Yves-Alexis Perez corsac@debian.org 2018-04-27T09:51:04+00:00 urn:sha1:3456101fa5dfd78d8b74c005b8dad281bb045398 allow access to {,/var}/run/notify closes: #896813 2017-06-30T11:52:01+00:00 Gerald Turner gturner@unzane.com 2017-05-12T00:15:09+00:00 urn:sha1:b8ac1d49802dbadecb1805baf4d6ca0ac7735ef0 The AppArmor profile for charon-systemd was copied from the existing profile for /usr/lib/ipsec/charon without much scrutiny other than testing basic IPsec tunnels (no fancy plugin options were tested). It appears that the team at Canonical that had written the /usr/lib/ipsec/charon policy had done extensive testing with several plugins, and it seems likely that applying the same profile to charon-systemd will allow those plugins to continue to work. The AppArmor profile for swanctl was written from scratch and well tested. It turns out that swanctl unnecessarily loads plugins by default, so a bit of frivolous access has been granted.