Activity log for bug #1773956

Date Who What changed Old value New value Message
2018-05-29 10:23:54 Jean-Daniel Dupas bug added bug
2018-05-30 15:36:09 Joshua Powers bug watch added https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866327
2018-05-30 15:36:10 Joshua Powers strongswan (Ubuntu): status New Confirmed
2018-05-30 15:36:12 Joshua Powers strongswan (Ubuntu): importance Undecided High
2018-05-30 15:36:19 Joshua Powers bug added subscriber Ubuntu Server
2018-12-03 12:30:12 Christian Ehrhardt  bug added subscriber Christian Ehrhardt 
2018-12-03 13:35:24 Christian Ehrhardt  nominated for series Ubuntu Cosmic
2018-12-03 13:35:24 Christian Ehrhardt  bug task added strongswan (Ubuntu Cosmic)
2018-12-03 13:35:24 Christian Ehrhardt  nominated for series Ubuntu Bionic
2018-12-03 13:35:24 Christian Ehrhardt  bug task added strongswan (Ubuntu Bionic)
2018-12-03 13:35:44 Christian Ehrhardt  strongswan (Ubuntu Bionic): status New Incomplete
2018-12-03 13:35:45 Christian Ehrhardt  strongswan (Ubuntu Cosmic): status New Incomplete
2018-12-03 13:35:47 Christian Ehrhardt  strongswan (Ubuntu): status Confirmed Triaged
2018-12-03 15:06:55 Launchpad Janitor merge proposal linked https://code.launchpad.net/~paelzer/ubuntu/+source/strongswan/+git/strongswan/+merge/360004
2018-12-05 15:52:43 Andreas Hasenack strongswan (Ubuntu): status Triaged In Progress
2018-12-05 15:52:49 Andreas Hasenack strongswan (Ubuntu): assignee Christian Ehrhardt  (paelzer)
2018-12-05 20:13:51 Andreas Hasenack strongswan (Ubuntu Cosmic): status Incomplete Confirmed
2018-12-05 20:13:53 Andreas Hasenack strongswan (Ubuntu Bionic): status Incomplete Confirmed
2018-12-07 11:26:36 Launchpad Janitor strongswan (Ubuntu): status In Progress Fix Released
2018-12-07 11:26:36 Launchpad Janitor cve linked 2018-16151
2018-12-07 11:26:36 Launchpad Janitor cve linked 2018-16152
2018-12-07 11:26:36 Launchpad Janitor cve linked 2018-17540
2018-12-10 07:25:44 Christian Ehrhardt  strongswan (Ubuntu): status Fix Released Triaged
2018-12-10 07:25:46 Christian Ehrhardt  strongswan (Ubuntu Bionic): status Confirmed Triaged
2018-12-10 07:25:47 Christian Ehrhardt  strongswan (Ubuntu Cosmic): status Confirmed Triaged
2018-12-10 07:55:23 Launchpad Janitor merge proposal linked https://code.launchpad.net/~paelzer/ubuntu/+source/strongswan/+git/strongswan/+merge/360447
2018-12-10 07:57:44 Christian Ehrhardt  strongswan (Ubuntu): status Triaged In Progress
2018-12-10 08:08:45 Christian Ehrhardt  description When using the HA plugin, charon-systemd try to read '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' and to write in files into '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' So the 2 rules may be append to charon-systemd.apparmor.conf # Cluster IP @{PROC}/@{pid}/net/ipt_CLUSTERIP/ r, @{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw, [Impact] * when using the ha plugin an apparmor Deny is triggered * Fix by allowing charon to access CLUSTERIP [Test Case] * get a VM to test this as it might mess up your networking * install strongswan (which pulls in libcharon-extra-plugins) * Edit /etc/strongswan.d/charon/ha.conf to something like: ha { load = yes local = 192.168.122.248 monitor = yes remote = 192.168.122.94 resync = yes segment_count = 2 } With your IP and a peer IP (both KVM guests for me) * $ sudo iptables -I INPUT -i ens3 -d 10.10.10.10 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 1 Please make sure your network device matches above, the IPs can be kept as-is unless you have a collision * With that set up restart the service $ sudo restart strongswan * Without the fix this will break the ha plugin early based on the mentioned apparmor DENY Note: this does not provide a full ha setup, since this simple setup is enough to trigger and verify the issue. [Regression Potential] * This is only opening up one more (actually uncommon other than HA setups) path to charon, I'd not expect existing functionality to regress due to that. [Other Info] * n/a ---- When using the HA plugin, charon-systemd try to read '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' and to write in files into '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' So the 2 rules may be append to charon-systemd.apparmor.conf # Cluster IP @{PROC}/@{pid}/net/ipt_CLUSTERIP/ r, @{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw,
2018-12-11 12:01:22 Christian Ehrhardt  description [Impact] * when using the ha plugin an apparmor Deny is triggered * Fix by allowing charon to access CLUSTERIP [Test Case] * get a VM to test this as it might mess up your networking * install strongswan (which pulls in libcharon-extra-plugins) * Edit /etc/strongswan.d/charon/ha.conf to something like: ha { load = yes local = 192.168.122.248 monitor = yes remote = 192.168.122.94 resync = yes segment_count = 2 } With your IP and a peer IP (both KVM guests for me) * $ sudo iptables -I INPUT -i ens3 -d 10.10.10.10 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 1 Please make sure your network device matches above, the IPs can be kept as-is unless you have a collision * With that set up restart the service $ sudo restart strongswan * Without the fix this will break the ha plugin early based on the mentioned apparmor DENY Note: this does not provide a full ha setup, since this simple setup is enough to trigger and verify the issue. [Regression Potential] * This is only opening up one more (actually uncommon other than HA setups) path to charon, I'd not expect existing functionality to regress due to that. [Other Info] * n/a ---- When using the HA plugin, charon-systemd try to read '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' and to write in files into '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' So the 2 rules may be append to charon-systemd.apparmor.conf # Cluster IP @{PROC}/@{pid}/net/ipt_CLUSTERIP/ r, @{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw, [Impact]  * when using the ha plugin an apparmor Deny is triggered  * Fix by allowing charon to access CLUSTERIP [Test Case]  * get a VM to test this as it might mess up your networking  * install strongswan (which pulls in libcharon-extra-plugins)  * Edit /etc/strongswan.d/charon/ha.conf to something like:           ha {          load = yes          local = 192.168.122.248          monitor = yes          remote = 192.168.122.94          resync = yes          segment_count = 2      }    With your IP and a peer IP (both KVM guests for me)  * $ sudo iptables -I INPUT -i ens3 -d 10.10.10.10 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 1    Please make sure your network device matches above, the IPs can be kept as-is unless you have a collision  * With that set up restart the service    $ sudo systemctl restart strongswan  * Without the fix this will break the ha plugin early based on the    mentioned apparmor DENY  Note: this does not provide a full ha setup, since this simple setup is        enough to trigger and verify the issue. [Regression Potential]  * This is only opening up one more (actually uncommon other than HA    setups) path to charon, I'd not expect existing functionality to    regress due to that. [Other Info]  * n/a ---- When using the HA plugin, charon-systemd try to read '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' and to write in files into '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' So the 2 rules may be append to charon-systemd.apparmor.conf # Cluster IP @{PROC}/@{pid}/net/ipt_CLUSTERIP/ r, @{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw,
2018-12-11 12:22:46 Christian Ehrhardt  description [Impact]  * when using the ha plugin an apparmor Deny is triggered  * Fix by allowing charon to access CLUSTERIP [Test Case]  * get a VM to test this as it might mess up your networking  * install strongswan (which pulls in libcharon-extra-plugins)  * Edit /etc/strongswan.d/charon/ha.conf to something like:           ha {          load = yes          local = 192.168.122.248          monitor = yes          remote = 192.168.122.94          resync = yes          segment_count = 2      }    With your IP and a peer IP (both KVM guests for me)  * $ sudo iptables -I INPUT -i ens3 -d 10.10.10.10 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 1    Please make sure your network device matches above, the IPs can be kept as-is unless you have a collision  * With that set up restart the service    $ sudo systemctl restart strongswan  * Without the fix this will break the ha plugin early based on the    mentioned apparmor DENY  Note: this does not provide a full ha setup, since this simple setup is        enough to trigger and verify the issue. [Regression Potential]  * This is only opening up one more (actually uncommon other than HA    setups) path to charon, I'd not expect existing functionality to    regress due to that. [Other Info]  * n/a ---- When using the HA plugin, charon-systemd try to read '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' and to write in files into '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' So the 2 rules may be append to charon-systemd.apparmor.conf # Cluster IP @{PROC}/@{pid}/net/ipt_CLUSTERIP/ r, @{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw, [Impact]  * when using the ha plugin an apparmor Deny is triggered  * Fix by allowing charon to access CLUSTERIP [Test Case]  * get a VM to test this as it might mess up your networking  * install strongswan and libcharon-extra-plugins $ sudo apt install strongswan libcharon-extra-plugins  * Edit /etc/strongswan.d/charon/ha.conf to something like:           ha {          load = yes          local = 192.168.122.248          monitor = yes          remote = 192.168.122.94          resync = yes          segment_count = 2      }    With your IP and a peer IP (both KVM guests for me)  * $ sudo iptables -I INPUT -i ens3 -d 10.10.10.10 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 1    Please make sure your network device matches above, the IPs can be kept as-is unless you have a collision  * With that set up restart the service    $ sudo systemctl restart strongswan  * Without the fix this will break the ha plugin early based on the    mentioned apparmor DENY  Note: this does not provide a full ha setup, since this simple setup is        enough to trigger and verify the issue. [Regression Potential]  * This is only opening up one more (actually uncommon other than HA    setups) path to charon, I'd not expect existing functionality to    regress due to that. [Other Info]  * n/a ---- When using the HA plugin, charon-systemd try to read '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' and to write in files into '@{PROC}/@{pid}/net/ipt_CLUSTERIP/' So the 2 rules may be append to charon-systemd.apparmor.conf # Cluster IP @{PROC}/@{pid}/net/ipt_CLUSTERIP/ r, @{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw,
2018-12-12 15:09:20 Launchpad Janitor merge proposal linked https://code.launchpad.net/~paelzer/ubuntu/+source/strongswan/+git/strongswan/+merge/360800
2018-12-12 15:10:26 Christian Ehrhardt  merge proposal linked https://code.launchpad.net/~paelzer/ubuntu/+source/strongswan/+git/strongswan/+merge/360801
2018-12-13 15:42:41 Launchpad Janitor strongswan (Ubuntu): status In Progress Fix Released
2018-12-18 17:21:00 Brian Murray strongswan (Ubuntu Cosmic): status Triaged Fix Committed
2018-12-18 17:21:01 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2018-12-18 17:21:04 Brian Murray bug added subscriber SRU Verification
2018-12-18 17:21:07 Brian Murray tags verification-needed verification-needed-cosmic
2018-12-18 17:27:46 Brian Murray strongswan (Ubuntu Bionic): status Triaged Fix Committed
2018-12-18 17:27:52 Brian Murray tags verification-needed verification-needed-cosmic verification-needed verification-needed-bionic verification-needed-cosmic
2019-01-07 15:09:23 Christian Ehrhardt  tags verification-needed verification-needed-bionic verification-needed-cosmic verification-done verification-done-bionic verification-done-cosmic
2019-01-08 17:37:21 Launchpad Janitor strongswan (Ubuntu Bionic): status Fix Committed Fix Released
2019-01-08 17:37:31 Brian Murray removed subscriber Ubuntu Stable Release Updates Team
2019-01-08 17:37:49 Launchpad Janitor strongswan (Ubuntu Cosmic): status Fix Committed Fix Released