[Apparmor-dev] AA3 - Profile Layout

[John Johansen]

I thought we could start the AppArmor 3 discussion out with something
hopefully not too controversial.

The goal for profile management is to develop a standard covering:
packaging, multiple repositories, local updates, profile dependencies,
and change tracking.  A immediate goal is to resolve the
issues AppArmor's current layout has with an eye to the future so
what we do now won't cause problems later.

  Current Issues:
  - Packages install profiles into directly into /etc/apparmor.d/ but
    the tools modify those same profiles, which can result in packaging
    conflicts.
  - enable/disabling of profiles is not standardized and requires either
    renaming profiles owned by package management or adding supplemental
    information and updating the init scripts.
  - It does not handle multiple profile sources well
  - Profile flags for enforce and complain modes are stored in the
    profiles.  Toggling modes can cause conflicts with package
    management
  - Profiles can depend on abstractions or other profiles as determined
    by px and pix transitions.
  - Interaction of profile repository and package profiles is not
    codified.  eg.  What install using packages but decided to update
    via repository.
  - Profile namespaces are not codified in the current layout
  - The Handling of policy between different kernels and different
    versions of AppArmor is not codified or well supported.
    eg. User has two different kernels installed that support different
        feature sets.

  Goals
  - Local changes and configs are honored. ie.
    - packaging systems should not over ride local config and profile
      changes.  Enabled/Disabled profiles should remain
      enabled/disabled.
      Profile and variable changes should be retained.
    - Package updates should be able to complete automatically where
      possible.
    - The administrator should be able to configure which changes
      can be handled automaticly, and which need administrator
      intervention.
      eg.  An administrator should have control over whether a new
      profile
      in a package will get enabled.
    - Package system dependency resolution should be used where
      possible.
  - Ease management of conflicts caused by local updates and package or
    repository updates.
  - Standardize how profiles are enabled/disabled and where they are
    stored
  - Allow for multiple profile repositories.
  - Allow enabled profile set to be a mix of profiles from different
    repositories.
  - Standardize how packages interact with profile repositories, and how
    dependency conflicts can be resolved.
  - Standardize where and how repository and dependency meta data are
    stored.  Is it stored in the profile, is it stored in a db or
    supplemental file.
  - Standardize precompiled profile cache layout
  - Allow package management to detect and track local changes, and
    preferences to
    profiles and abstractions supplied by a package.


Proposal for profile layout:
  The /etc/apparmor/ and /etc/apparmor.d/ directories are retained, in
  their current format, ie. /etc/apparmor/ is used for configuration and
  /etc/apparmor.d/ stores active profiles.  The basic layout of the
  directories are not changed, maintaining compatability with the
  the current layout.

  Profiles can be disabled by removing them from /etc/apparmor.d/ or
  by placing a symlink to them in the /etc/apparmor.d/disabled/
  directory. Profiles can be enabled by making a soft link or copying
  them into /etc/apparmor.d/, or if their is a symlink in
  /etc/apparmor.d/disabled by removing it.

  The .cache directory will be used to store precompiled profiles.
  The .merge file will be used to help determine which profiles need
  merging after an update.

  Profile namespaces will have the same general layout except that the
  directory describing the namespace is embedded in /etc/apparmor.d/
  Profile namespace directories should have a common prefix (ns_ or
  namespace_), so that the tools can determine their purpose.


Package management and Profile Layout

  Package management should not install profiles directly into
  /etc/apparmor.d/.  Instead package managment should store active
  profiles into a location available at boot
  (/etc/apparmor/profiles/<package> is recommended), and then either
  place a soft link to the profile in /etc/apparmor.d/, or place a copy
  of the profile with a source header in /etc/apparmor.d/.  The goal
  being to keep the profiles installed from packages pristine so as to
  not cause package management conflicts.

  The AppArmor tools will be modified to detect and break the soft link
  when a profile is modified, replacing it with a copy of the profile
  and accompanyning source header.

  The source header is the local profile equivalent of the repository
  header.  It is not required but if present it is used by the tools to
  track which profile the current profile was derived from, enabling
  profile merging.

  Package management should respect local changes and not enable
  profiles that have been enabled/disabled locally.

  The goal being to create a set of macros for each package management
  system that handles the details of updating of profiles.  The basic
  management macro have a form similar to

    install_profile(<file>, <default enabled/disabled>)

    remove_profile(<file>)


Change Tracking
  One of the goals of revising profile management is enabling improved
  change tracking, and merging.  Keeping a pristine copy of a profile
  allows for profile management to determine any changes made to local
  profiles.  These changes can then be applied to profile updates,
  either automatically or on a change by change basis.

  The goal is to add a new merge tool, that will be capable of doing
  2 and 3 way semantic profile merges.  Where a 2 way merge creates
  a new profile containing all of the privileges of both profiles,
  and the 3 way merge can be used to merge over additions and
  subtraction of privileges.

  The full specification for change tracking is not being proposed at
  this time.  Both 2 way and 3 way merging should be able to be run
  fully automated or in an interactive mode.  If interactive mode is
  desired it may have to be done after package management is done
  doing its profile updates.

  The .merge file will be used to store which profiles need merging
  after an update.


Profile Modes and flags
  Currently AppArmor requires modification to the profile file to change
  the profile mode, or to disable/enable them.  This is problematic for
  package management systems, this is why it is proposed that package
  management not own the profiles in /etc/apparmor.d/

  Ubuntu has added the force-complain, and disabled directories to
  support changing profiles without updating the repository file.
  These directories will be officially supported, but moving to the
  proposed profile management will be encouraged.


Profile meta tags
  The proposal is to just extend the current meta tag syntax used for
  repository profiles.  This does make it so a plain diff, or md5
  can't be used to detect changes.

  The goal is to have a semantic profile diff which should help mitigate
  this problem.  The alternative to using meta tags in the profile is
  to use an external file (probably a dot file) to store the meta
  information. While doing this allows a diff or md5 to be used to test
  if a profile is the same, it doesn't make the meta information
  immediately available in the profile.