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 |
|