Ubuntu
apparmor package

Change in kernel stacking behavior causes regression tests to fail

Bug #1628295 reported by Tyler Hicks
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Fix Released
Low
Tyler Hicks
Trusty
Fix Released
Low
Tyler Hicks
Xenial
Fix Released
Low
Tyler Hicks
Yakkety
Fix Released
Low
Tyler Hicks

Bug Description

[Impact]

 * Two regression tests fail due to a behavior change in recent Xenial and Yakkety kernels

 * Adjusting the regression tests appropriately allows the kernel and security teams to use QRT's test-apparmor.py to test kernel and userspace AppArmor changes with confidence

[Test Case]

$ apt-get source apparmor # make sure this fetches the new apparmor source
$ sudo apt-get install libapparmor-dev
$ cd tests/regression/apparmor
$ make USE_SYSTEM=1
$ sudo bash stackonexec.sh
Error: transition failed. Test 'STACKONEXEC (stacked with unconfined - okcon)' was expected to 'pass'. Reason for failure 'FAIL - current mode "enforce" != expected_mode "mixed"'
Error: transition passed. Test 'STACKONEXEC (stacked with unconfined - bad mode)' was expected to 'fail'
$ sudo bash stackprofile.sh
Error: transition failed. Test 'STACKPROFILE (stacked with unconfined - okcon)' was expected to 'pass'. Reason for failure 'FAIL - current mode "enforce" != expected_mode "mixed"'

The two previous commands should result in no output and return value of 0 once
the regression test is properly updated.

[Regression Potential]

 * This is an extremely low risk change since it only touches regression testing code that is not user-facing.

[Other Info]

 * This bug has already been fixed upstream:

   https://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3505

See original description
Tyler Hicks (tyhicks)
Changed in apparmor (Ubuntu Xenial):
importance: Undecided → Low
Changed in apparmor (Ubuntu Trusty):
importance: Undecided → Low
Changed in apparmor (Ubuntu Xenial):
assignee: nobody → Tyler Hicks (tyhicks)
Changed in apparmor (Ubuntu Trusty):
assignee: nobody → Tyler Hicks (tyhicks)
Revision history for this message
Stéphane Graber (stgraber) wrote : Please test proposed package

Hello Tyler, or anyone else affected,

Accepted apparmor into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apparmor (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10.95-4ubuntu5

---------------
apparmor (2.10.95-4ubuntu5) yakkety; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
    debian/apparmor.service, debian/apparmor.upstart,
    debian/lib/apparmor/profile-load: Adjust the checks that previously kept
    AppArmor policy from being loaded while booting a container. Now we
    attempt to load policy if we're in a LXD or LXC managed container that is
    using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests so that the kernel SRU process is not interrupted by
    failing tests
    - debian/patches/r3505-tests-fix-stacking-mode-checks.patch: Fix the
      stackonexec.sh and stackprofile.sh tests (LP: #1628295)
    - debian/patches/r3509-tests-fix-exec_stack-errors.patch: Fix the
      exec_stack.sh test (LP: #1628745)

 -- Tyler Hicks <email address hidden> Thu, 29 Sep 2016 00:38:47 -0500

Changed in apparmor (Ubuntu Yakkety):
status: In Progress → Fix Released
Tyler Hicks (tyhicks)
description: updated
Revision history for this message
Tyler Hicks (tyhicks) wrote :

I've completed the AppArmor test plan:

  https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor

I've also manually verified the AppArmor portion of this SRU with the kernel currently in xenial-updates (4.4.0-45.66) and the kernel in xenial-proposed (4.4.0-46.67), which contains a number of AppArmor changes.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---------------
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
    debian/apparmor.service, debian/apparmor.upstart,
    debian/lib/apparmor/profile-load: Adjust the checks that previously kept
    AppArmor policy from being loaded while booting a container. Now we
    attempt to load policy if we're in a LXD or LXC managed container that is
    using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
    interrupted by failing tests whenever the AppArmor stacking features are
    backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
    receives a 4.8 or newer kernel
    - debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
      exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
    - debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
      exec_stack.sh fix mentioned above to more accurately test kernels older
      than 4.8 (LP: #1630069)
    - debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
      patch earlier in the series, as to match when it was committed upstream,
      so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks <email address hidden> Fri, 07 Oct 2016 05:21:44 +0000

Changed in apparmor (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.3 KiB)

This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5~14.04.1

---------------
apparmor (2.10.95-0ubuntu2.5~14.04.1) trusty; urgency=medium

  * Bring apparmor 2.10.95-0ubuntu2.5, from Ubuntu 16.04, to Ubuntu 14.04.
    - This allows for proper snap confinement on Ubuntu 14.04 when using the
      hardware enablement kernel (LP: #1641243)
  * Changes made on top of 2.10.95-0ubuntu2.5:
    - debian/apparmor.upstart: Remove the upstart job and continue using the
      init script in 14.04
    - debian/apparmor.postinst, debian/apparmor-profiles.postinst,
      debian/apparmor-profiles.postrm, debian/rules: Revert to using
      invoke-rc.d to load the profiles, rather than reloading them directly,
      since 14.04 will continue using the init script rather than the upstart
      job.
    - debian/apparmor.init, debian/lib/apparmor/functions,
      debian/apparmor.postinst, debian/apparmor.postrm: Remove functionality
      dealing with AppArmor policy in system image based environments since
      this 14.04 package will not need to handle such environments. This
      removes the handle_system_policy_package_updates(),
      compare_previous_version(), compare_and_save_debsums() functions and
      their callers.
    - debian/apparmor.init: Continue using running-in-container since
      systemd-detect-virt doesn't exist on 14.04
    - debian/lib/apparmor/functions, debian/apparmor.init: Remove the
      is_container_with_internal_policy() function and adjust its call sites
      in apparmor.init so that AppArmor policy is not loaded inside of 14.04
      LXD containers (avoids bug #1641236)
    - debian/lib/apparmor/profile-load, debian/apparmor.install: Remove
      profile-load as upstart's apparmor-profile-load is used in 14.04
    - debian/patches/libapparmor-mention-dbus-method-in-getcon-man.patch:
      Continue applying this patch since the dbus version in 14.04 isn't new
      enough to support fetching the AppArmor context from
      org.freedesktop.DBus.GetConnectionCredentials().
    - debian/patches/libapparmor-force-libtoolize-replacement.patch: Force
      libtoolize to replace existing files to fix a libapparmor FTBFS issue on
      14.04.
    - debian/control: Retain the original 14.04 Breaks and ignore the new
      Breaks from 2.10.95-0ubuntu2.5 since they were put in place as part of
      the enablement of UNIX domain socket mediation. They're not needed in
      this upload since UNIX domain socket mediation is disabled by default so
      updates to the profiles included in those packages are not needed.
    - Preserve the profiles and abstractions from 14.04's
      2.8.95~2430-0ubuntu5.3 apparmor package by recreating them in the
      top-level profiles-14.04/ directory of the source. They'll be installed
      to debian/tmp/etc/apparmor.d/ during the build process and then to
      /etc/apparmor.d/ on package install so that there are no changes to the
      shipped profiles or abstractions. The abstractions from
      2.10.95-0ubuntu2.5 will be installed into
      debian/tmp/snap/etc/apparmor.d/ during the build process and then into
      /etc/apparmor.d/snap/abstractions/ on package install for use wit...

Read more...

Changed in apparmor (Ubuntu Trusty):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.