ApparmorPolicyLoad

Contents

  1. Meeting

Meeting

From http://pad.ubuntu.com/XPpN9XI26L: 

A) old kernel - old parser - old policy -> OK
B) old kernel - old parser - new policy -> policy doesn't compile
C) old kernel - new parser - old policy -> usually OK
D) old kernel - new parser - new policy -> policy compiles with warnings, loads
E) new kernel - old parser - old policy -> policy compiles, loads, possibly breaks apps
F) new kernel - old parser - new policy -> policy doesn't compile
G) new kernel - new parser - old policy -> policy compiles, loads, possibly breaks apps
H) new kernel - new parser - new policy -> OK
A and H are normal running conditions
B, C, D can happen during upgrades
What about E F G?
terminology:
updates: regular security updates, for example
upgrades: release to release upgrades
B)  - During distro updates: FAIL: We should handle this gracefully before releasing
     - During distro upgrades: Currently: package that ships a confined service will fail to install if we
       don't ignore policy load failure.
       - Two mitigation options:
         A: don't fail package installation if service fails to start because of AppArmor policy failing
            to load
         B: add tag to profile to allow policy to FAIL to load
     - During developer package uploads: FAIL: Should be tested before uploading
     - Backported packages/SRUs: FAIL: We should handle this gracefully before releasing
C)  - During distro upgrades: Currently: package that ships a confined service will fail to install if we
      don't ignore policy load failure.
       - Two mitigation options:
         A: don't fail package installation if service fails to start because of AppArmor policy failing to
            load
         B: add tag to profile to allow policy to FAIL to load
         C: fix parser to store off old autogenerated names, and compare against new auto-generated names,
            so we can properly support old names
     - During developer package uploads: FAIL: Should be tested before uploading
D) - Classic upgrade scenario: should just work (may need clove of garlic and/or goat sacrifice)
    - Backported packages/SRUs: FAIL: We should handle this gracefully before releasing
E - can happen during upgrade as we don't make the kernel depend on the parser, so its possible we get a
    new kernel with say a caps change and don't roll out a new parser with that change: (Current raring
    backport situation): Application may fail
   - from a none distro supported perspective it happens all the time with custom kernels
   - Mitigation options:
     - nothing for us other than fixing the bug when it is reported
     - QA could test everything with apparmor profiles prior to pushing lts backport kernel to catch some
       stuff
   
F) - (When using a backported kernel): Backported packages/SRUs: FAIL: We should handle this gracefully
     before releasing
       - Two mitigation options:
         A: don't fail package installation if service fails to start because of AppArmor policy failing
            to load
         B: add tag to profile to allow policy to FAIL to load
G - During distro updates in the devel release (ie upgrading from v2 to v3, and policy is packaged in an
    app and the app doesn't update its policy)
    - During distro upgrades (backport kernel on upgrade (eg precise with saucy lts kernel to 14.04)):
      Currently: package that ships a confined service will fail to install if we don't ignore policy load
      failure
    - Mitigation options:
      - Convert to new policy on the fly: most failures can be avoided by adding 'open' rules for v2 policy.
        ie, if the policy is v2, the parser can notice that and add a 'dbus,' rule so that it is actually
        new policy that behaves like the old. Discerning v2 policy vs v3 can be handled in the files 
        themselves or via a directory. v2 profiles should be be required to change. John will send an email
        to the list regarding this

SecurityTeam/Specifications/ApparmorPolicyLoad (last edited 2013-10-24 20:54:18 by jdstrand)