Comment 8 for bug 1641243

I've completed my verification of the apparmor 2.10.95-0ubuntu2.5~14.04.1 SRU. Testing very went well and I did not uncover any issues. I completed the entire Test Case as documented in the bug description. The AppArmor test plan was completed on the 14.04 release and HWE kernels as well as all of the regression tests from QRT. The manual testing of evince was also performed on the release and HWE kernels. Additionally, I ran test-apparmor.py on the i386 release and HWE kernels (all other tests were ran on amd64).

On the HWE kernel, I was able to test apparmor with the snapd in trusty-proposed. The pwgen-tyhicks, hello-world, and lxd snaps all seemed to be working correctly. I created a 16.04 LXD container and verified that confinement was working as intended. I also verified that confinement was working properly with hello-world.sh.

As for the 12.04 -> 14.04 upgrade testing, it also went very well. I installed most major 12.04 packages containing an AppArmor profile, in addition to what's present in a default desktop install, and performed an upgrade:

$ sudo apt-get install slapd mysql-server clamav tcpdump ntp
...

$ sudo aa-status
...
26 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/evince
   /usr/bin/evince-previewer
   /usr/bin/evince-previewer//launchpad_integration
   /usr/bin/evince-previewer//sanitized_helper
   /usr/bin/evince-thumbnailer
   /usr/bin/evince-thumbnailer//sanitized_helper
   /usr/bin/evince//launchpad_integration
   /usr/bin/evince//sanitized_helper
   /usr/bin/freshclam
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/lightdm/lightdm-guest-session
   /usr/lib/lightdm/lightdm-guest-session//chromium
   /usr/lib/telepathy/mission-control-5
   /usr/lib/telepathy/telepathy-*
   /usr/lib/telepathy/telepathy-*//pxgsettings
   /usr/lib/telepathy/telepathy-*//sanitized_helper
   /usr/lib/telepathy/telepathy-ofono
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/mysqld
   /usr/sbin/ntpd
   /usr/sbin/slapd
   /usr/sbin/tcpdump
...

There were a couple denials logged but they didn't affect the upgrade:

$ grep DENIED /var/log/syslog
Dec 16 18:00:41 sec-precise-amd64 kernel: [ 8267.110822] type=1400 audit(1481911241.875:29): apparmor="DENIED" operation="open" parent=6862 profile="/usr/sbin/slapd" name="/etc/pkcs11/modules/" pid=6873 comm="slapd" requested_mask="r" denied_mask="r" fsuid=118 ouid=0
Dec 16 18:32:21 sec-precise-amd64 kernel: [ 1766.776830] type=1400 audit(1481913141.561:35): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/mysqld" name="/proc/sys/vm/overcommit_memory" pid=29835 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=116 ouid=0

I then performed the same 12.04 -> 14.04 upgrade test except that I didn't use the new apparmor from trusty-proposed and it turns out that I see the same two AppArmor denials:

$ grep DENIED /var/log/syslog
Dec 16 21:03:18 sec-precise-amd64 kernel: [ 739.903410] type=1400 audit(1481922198.702:34): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/mysqld" name="/proc/sys/vm/overcommit_memory" pid=1679 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=116 ouid=0
Dec 16 21:03:18 sec-precise-amd64 kernel: [ 740.079754] type=1400 audit(1481922198.878:35): apparmor="DENIED" operation="open" parent=1747 profile="/usr/sbin/slapd" name="/etc/pkcs11/modules/" pid=1760 comm="slapd" requested_mask="r" denied_mask="r" fsuid=118 ouid=0

In other words, the apparmor package from trusty-proposed does not regress the 12.04 -> 14.04 upgrade process.

I feel like the apparmor 2.10.95-0ubuntu2.5~14.04.1 SRU has went through very thorough testing and that it is good to go.