** Description changed: + SRU Justification: + + [ Impact ] + Configuration of an OpenVPN client with a "remote some_hostname.local" rule on Plucky fails because the OpenVPN profile does not allow access to /run/avahi-daemon/socket for mDNS lookups. + + [ Test Plan ] + + Test plan for the openvpn bugs: + * This test description assumes no access to existing machines that use OpenVPN. Additional testing of OpenVPN in related configurations (other virtualization solutions, specifying the server location via IPs or actual domains, etc.) is encouraged. + - Spin up two Ubuntu Plucky VMs, one of which will be referred to as openvpn-client and the other of which will be referred to as openvpn-server + - Ensure that the two machines are able to ping each other using a [machine hostname].local address + - Generate a key using `openvpn --genkey secret secret.key` and transfer this key to both machines, somewhere inside the home directory + - Place the following configuration onto openvpn-server, next to secret.key: + dev tun + proto udp + cipher aes-256-cbc + ifconfig 10.4.13.1 10.4.13.2 + secret static.key + - Place the following configuration onto openvpn-client, next to secret.key, substituting the remote location: + remote openvpn-server.local + dev tun + proto udp + cipher aes-256-cbc + ifconfig 10.4.3.2 10.4.13.1 + secret static.key + - Ensure that the "remote" line in the client configuration is using a .local address + - Launch openvpn on both machines by running `openvpn path_to_config` on each + - If (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure + - Ensure that the two machines are able to ping each other through the OpenVPN tunnel + + [ Where problems could occur ] + + Allowing mDNS access in the openvpn profile is loosening confinement on + a profile. However, if a user manually modified the installed profiles, + then the package upgrade would cause conflicts, and rejection of the + incoming changes (either by hand during an interactive upgrade or + automatically during an batch unattended upgrade) would result in end + users not getting the packaged fix. + + [ Other Info ]
** Description changed: SRU Justification: [ Impact ] Configuration of an OpenVPN client with a "remote some_hostname.local" rule on Plucky fails because the OpenVPN profile does not allow access to /run/avahi-daemon/socket for mDNS lookups. [ Test Plan ] Test plan for the openvpn bugs: - * This test description assumes no access to existing machines that use OpenVPN. Additional testing of OpenVPN in related configurations (other virtualization solutions, specifying the server location via IPs or actual domains, etc.) is encouraged. - - Spin up two Ubuntu Plucky VMs, one of which will be referred to as openvpn-client and the other of which will be referred to as openvpn-server - - Ensure that the two machines are able to ping each other using a [machine hostname].local address - - Generate a key using `openvpn --genkey secret secret.key` and transfer this key to both machines, somewhere inside the home directory - - Place the following configuration onto openvpn-server, next to secret.key: - dev tun - proto udp - cipher aes-256-cbc - ifconfig 10.4.13.1 10.4.13.2 - secret static.key - - Place the following configuration onto openvpn-client, next to secret.key, substituting the remote location: - remote openvpn-server.local - dev tun - proto udp - cipher aes-256-cbc - ifconfig 10.4.3.2 10.4.13.1 - secret static.key - - Ensure that the "remote" line in the client configuration is using a .local address - - Launch openvpn on both machines by running `openvpn path_to_config` on each - - If (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure - - Ensure that the two machines are able to ping each other through the OpenVPN tunnel + * This test description assumes no access to existing machines that use OpenVPN. Additional testing of OpenVPN in related configurations (other virtualization solutions, specifying the server location via IPs or actual domains, etc.) is encouraged. + - Spin up two Ubuntu Plucky VMs, one of which will be referred to as openvpn-client and the other of which will be referred to as openvpn-server + - Ensure that the two machines are able to ping each other using a [machine hostname].local address + - Generate a key using `openvpn --genkey secret secret.key` and transfer this key to both machines, somewhere inside the home directory + - Place the following configuration onto openvpn-server, next to secret.key: + dev tun + proto udp + cipher aes-256-cbc + ifconfig 10.4.13.1 10.4.13.2 + secret static.key + - Place the following configuration onto openvpn-client, next to secret.key, substituting the remote location: + remote openvpn-server.local + dev tun + proto udp + cipher aes-256-cbc + ifconfig 10.4.3.2 10.4.13.1 + secret static.key + - Ensure that the "remote" line in the client configuration is using a .local address + - Launch openvpn on both machines by running `openvpn path_to_config` on each + - If (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure + - Ensure that the two machines are able to ping each other through the OpenVPN tunnel [ Where problems could occur ] Allowing mDNS access in the openvpn profile is loosening confinement on a profile. However, if a user manually modified the installed profiles, then the package upgrade would cause conflicts, and rejection of the incoming changes (either by hand during an interactive upgrade or automatically during an batch unattended upgrade) would result in end users not getting the packaged fix. [ Other Info ] + + The OpenVPN setups in the test plans for LP: #2109029 and LP: #2107596 + are nearly identical. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2109029 Title: AppArmor OpenVPN profile blocks mDNS lookups Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Plucky: In Progress Status in apparmor source package in Questing: Fix Released Bug description: SRU Justification: [ Impact ] Configuration of an OpenVPN client with a "remote some_hostname.local" rule on Plucky fails because the OpenVPN profile does not allow access to /run/avahi-daemon/socket for mDNS lookups. [ Test Plan ] Test plan for the openvpn bugs: * This test description assumes no access to existing machines that use OpenVPN. Additional testing of OpenVPN in related configurations (other virtualization solutions, specifying the server location via IPs or actual domains, etc.) is encouraged. - Spin up two Ubuntu Plucky VMs, one of which will be referred to as openvpn-client and the other of which will be referred to as openvpn-server - Ensure that the two machines are able to ping each other using a [machine hostname].local address - Generate a key using `openvpn --genkey secret secret.key` and transfer this key to both machines, somewhere inside the home directory - Place the following configuration onto openvpn-server, next to secret.key: dev tun proto udp cipher aes-256-cbc ifconfig 10.4.13.1 10.4.13.2 secret static.key - Place the following configuration onto openvpn-client, next to secret.key, substituting the remote location: remote openvpn-server.local dev tun proto udp cipher aes-256-cbc ifconfig 10.4.3.2 10.4.13.1 secret static.key - Ensure that the "remote" line in the client configuration is using a .local address - Launch openvpn on both machines by running `openvpn path_to_config` on each - If (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure - Ensure that the two machines are able to ping each other through the OpenVPN tunnel [ Where problems could occur ] Allowing mDNS access in the openvpn profile is loosening confinement on a profile. However, if a user manually modified the installed profiles, then the package upgrade would cause conflicts, and rejection of the incoming changes (either by hand during an interactive upgrade or automatically during an batch unattended upgrade) would result in end users not getting the packaged fix. [ Other Info ] The OpenVPN setups in the test plans for LP: #2109029 and LP: #2107596 are nearly identical. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2109029/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
