** Description changed: + SRU Justification: + + [ Impact ] + + The openvpn profile lacked permissions to manage DNS settings for pushed + DHCP settings (LP: #2107596) + + [ Test Plan ] + + * 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. The VM setup instructions are identical to those in the test plan of LP: #2109029. + - 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 + - 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 + - Launch openvpn on both machines by running `openvpn path_to_config` on each + - If (openvpn-client "remote" config line is a domain name (.local or otherwise)) and (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure for LP: #2109029 + - Ensure that the two machines are able to ping each other through the OpenVPN tunnel + - Stop both openvpn instances and add the line `push "dhcp-option DOMAIN-SEARCH canonical.com"` to the openvpn-server config + - Launch openvpn on both machines again and ensure that the two machines are able to ping each other through the tunnel + + [ Where problems could occur ] + + The OpenVPN profile change in this SRU loosens 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 ] + + -------original bug description: + If the remote openvpn server is pushing DNS settings that include a domain, the "/etc/openvpn/update-resolv-conf" script will fail. The apparmor settings are missing a rule to allow setting a dns domain. Error from openvpn: sd_bus_open_system: Permission denied Error from apparmor: audit: type=1107 audit(1744925540.893:328): pid=1907 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/resolve1" interface="org.freedesktop.resolve1.Manager" member="SetLinkDomains" mask="send" name="org.freedesktop.resolve1" pid=10292 label="openvpn//update-resolv" peer_pid=888 peer_label="unconfined" Thanks for looking into this. - # lsb_release -rd Description: Ubuntu 25.04 Release: 25.04 # apt-cache policy apparmor apparmor: - Installed: 4.1.0~beta5-0ubuntu14 - Candidate: 4.1.0~beta5-0ubuntu14 - Version table: - *** 4.1.0~beta5-0ubuntu14 500 - 500 http://de.archive.ubuntu.com/ubuntu plucky/main amd64 Packages - 100 /var/lib/dpkg/status + Installed: 4.1.0~beta5-0ubuntu14 + Candidate: 4.1.0~beta5-0ubuntu14 + Version table: + *** 4.1.0~beta5-0ubuntu14 500 + 500 http://de.archive.ubuntu.com/ubuntu plucky/main amd64 Packages + 100 /var/lib/dpkg/status
** Description changed: SRU Justification: [ Impact ] - The openvpn profile lacked permissions to manage DNS settings for pushed - DHCP settings (LP: #2107596) + The openvpn profile lacked permissions to manage pushed DHCP settings, + causing openvpn to fail to work with servers that were pushing such + settings. [ Test Plan ] - * 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. The VM setup instructions are identical to those in the test plan of LP: #2109029. - - 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 - - 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 - - Launch openvpn on both machines by running `openvpn path_to_config` on each - - If (openvpn-client "remote" config line is a domain name (.local or otherwise)) and (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure for LP: #2109029 - - Ensure that the two machines are able to ping each other through the OpenVPN tunnel - - Stop both openvpn instances and add the line `push "dhcp-option DOMAIN-SEARCH canonical.com"` to the openvpn-server config - - Launch openvpn on both machines again and ensure that the two machines are able to ping each other through the 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. The VM setup instructions are identical to those in the test plan of LP: #2109029. + - 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 + - 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 + - Launch openvpn on both machines by running `openvpn path_to_config` on each + - If (openvpn-client "remote" config line is a domain name (.local or otherwise)) and (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure for LP: #2109029 + - Ensure that the two machines are able to ping each other through the OpenVPN tunnel + - Stop both openvpn instances and add the line `push "dhcp-option DOMAIN-SEARCH canonical.com"` to the openvpn-server config + - Launch openvpn on both machines again and ensure that the two machines are able to ping each other through the tunnel [ Where problems could occur ] The OpenVPN profile change in this SRU loosens 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 ] -------original bug description: If the remote openvpn server is pushing DNS settings that include a domain, the "/etc/openvpn/update-resolv-conf" script will fail. The apparmor settings are missing a rule to allow setting a dns domain. Error from openvpn: sd_bus_open_system: Permission denied Error from apparmor: audit: type=1107 audit(1744925540.893:328): pid=1907 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/resolve1" interface="org.freedesktop.resolve1.Manager" member="SetLinkDomains" mask="send" name="org.freedesktop.resolve1" pid=10292 label="openvpn//update-resolv" peer_pid=888 peer_label="unconfined" Thanks for looking into this. # lsb_release -rd Description: Ubuntu 25.04 Release: 25.04 # apt-cache policy apparmor apparmor: Installed: 4.1.0~beta5-0ubuntu14 Candidate: 4.1.0~beta5-0ubuntu14 Version table: *** 4.1.0~beta5-0ubuntu14 500 500 http://de.archive.ubuntu.com/ubuntu plucky/main amd64 Packages 100 /var/lib/dpkg/status ** Description changed: SRU Justification: [ Impact ] The openvpn profile lacked permissions to manage pushed DHCP settings, causing openvpn to fail to work with servers that were pushing such settings. [ Test Plan ] * 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. The VM setup instructions are identical to those in the test plan of LP: #2109029. - 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 - 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 - Launch openvpn on both machines by running `openvpn path_to_config` on each - If (openvpn-client "remote" config line is a domain name (.local or otherwise)) and (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure for LP: #2109029 - Ensure that the two machines are able to ping each other through the OpenVPN tunnel - Stop both openvpn instances and add the line `push "dhcp-option DOMAIN-SEARCH canonical.com"` to the openvpn-server config - Launch openvpn on both machines again and ensure that the two machines are able to ping each other through the tunnel [ Where problems could occur ] The OpenVPN profile change in this SRU loosens 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. + -------original bug description: If the remote openvpn server is pushing DNS settings that include a domain, the "/etc/openvpn/update-resolv-conf" script will fail. The apparmor settings are missing a rule to allow setting a dns domain. Error from openvpn: sd_bus_open_system: Permission denied Error from apparmor: audit: type=1107 audit(1744925540.893:328): pid=1907 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/resolve1" interface="org.freedesktop.resolve1.Manager" member="SetLinkDomains" mask="send" name="org.freedesktop.resolve1" pid=10292 label="openvpn//update-resolv" peer_pid=888 peer_label="unconfined" Thanks for looking into this. # lsb_release -rd Description: Ubuntu 25.04 Release: 25.04 # apt-cache policy apparmor apparmor: Installed: 4.1.0~beta5-0ubuntu14 Candidate: 4.1.0~beta5-0ubuntu14 Version table: *** 4.1.0~beta5-0ubuntu14 500 500 http://de.archive.ubuntu.com/ubuntu plucky/main amd64 Packages 100 /var/lib/dpkg/status -- 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/2107596 Title: Apparmor is missing rule for openvpn to set DNS domain 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 ] The openvpn profile lacked permissions to manage pushed DHCP settings, causing openvpn to fail to work with servers that were pushing such settings. [ Test Plan ] * 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. The VM setup instructions are identical to those in the test plan of LP: #2109029. - 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 - 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 - Launch openvpn on both machines by running `openvpn path_to_config` on each - If (openvpn-client "remote" config line is a domain name (.local or otherwise)) and (openvpn is unable to resolve the domain) and (apparmor is generating denials related to (m)DNS lookups), then report verification test failure for LP: #2109029 - Ensure that the two machines are able to ping each other through the OpenVPN tunnel - Stop both openvpn instances and add the line `push "dhcp-option DOMAIN-SEARCH canonical.com"` to the openvpn-server config - Launch openvpn on both machines again and ensure that the two machines are able to ping each other through the tunnel [ Where problems could occur ] The OpenVPN profile change in this SRU loosens 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. -------original bug description: If the remote openvpn server is pushing DNS settings that include a domain, the "/etc/openvpn/update-resolv-conf" script will fail. The apparmor settings are missing a rule to allow setting a dns domain. Error from openvpn: sd_bus_open_system: Permission denied Error from apparmor: audit: type=1107 audit(1744925540.893:328): pid=1907 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/resolve1" interface="org.freedesktop.resolve1.Manager" member="SetLinkDomains" mask="send" name="org.freedesktop.resolve1" pid=10292 label="openvpn//update-resolv" peer_pid=888 peer_label="unconfined" Thanks for looking into this. # lsb_release -rd Description: Ubuntu 25.04 Release: 25.04 # apt-cache policy apparmor apparmor: Installed: 4.1.0~beta5-0ubuntu14 Candidate: 4.1.0~beta5-0ubuntu14 Version table: *** 4.1.0~beta5-0ubuntu14 500 500 http://de.archive.ubuntu.com/ubuntu plucky/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2107596/+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
