provide systemd compatible cache loading library

[Jamie Strandboge]

This tracks the work related to moving AppArmor to systemd in support of bug 1379542.

[Jamie Strandboge (jdstrand)]

Added upstream task since that is what is in progress. Set Ubuntu task to Confirmed. Add systemd task since it needs an update to make it use the cache loading library.

[Martin Pitt (pitti)]

As for tracking systemd bugs I'd like to reduce importance, as we have bug 1438249 for tracking the fallback for vivid. So this is mostly optimization now, it shouldn't make a difference security wise, right? Please set back to High if I misunderstood this. Thanks!

[Steve Beattie (sbeattie)]

AppArmor 2.10 has been released: https://launchpad.net/apparmor/2.10/2.10

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 2.10-0ubuntu2

---------------
apparmor (2.10-0ubuntu2) wily; urgency=medium

  * debian/patches/aa-status-dont_require_python3-apparmor.patch:
    make aa-status(8) work even when python3-apparmor is not installed,
    otherwise dh_apparmor postinst snippets can fail (LP: #1480492)
  * debian/control: make apparmor-utils depend on the same package
    version of python3-apparmor

 -- Steve Beattie <email address hidden> Fri, 31 Jul 2015 16:35:03 -0700

[intrigeri (intrigeri)]

I could ask for help to the person who implemented the initial AppArmor support in systemd. But first I would need a clearer task description than "Add systemd task since it needs an update to make it use the cache loading library". What exactly do we need systemd to do?

[Seth Arnold (seth-arnold)]

Hello intrigeri, this one is a bit involved.

As it is systemd's support for AppArmor is to issue a change_profile call before executing a unit's executable. This requires the profile to already be loaded, which currently means a pre-task that calls apparmor_parser on the profile or waiting to run until after an apparmor unit file completes loading all profiles.

The parser currently knows how to drive the cache, invalidate it if any of the files involved in defining the profile are modified, etc. But it'd be nice if this functionality were exposed via a library that systemd could use so that it could compile (and cache) the policy if needed, it could load a cached policy if one exists and isn't stale.

Since different tools own different AppArmor policies (init scripts own /etc/apparmor.d/, snapd owns snapd policy, libvirt owns libvirt policy, docker owns docker policy, etc) this may need some effort to determine what we really want it to do.

I hope this helps. Thanks.

[Seth Arnold (seth-arnold)]

Sigh. https://xkcd.com/386/ on myself.

The parser just checks for mtime newer than the cache, not changes.

Thanks

[intrigeri (intrigeri)]

Thanks! So we still need an AppArmor task, not just a systemd one, right? (My question came up because all the AppArmor tasks are marked as "Fix released", and thus I thought the only remaining thing to do is on the systemd side, but your answer suggests that's not actually the case.)

[John Johansen (jjohansen)]

On 06/30/2017 07:52 PM, Seth Arnold wrote:
> Hello intrigeri, this one is a bit involved.
>
> As it is systemd's support for AppArmor is to issue a change_profile
> call before executing a unit's executable. This requires the profile to
> already be loaded, which currently means a pre-task that calls
> apparmor_parser on the profile or waiting to run until after an apparmor
> unit file completes loading all profiles.
>
> The parser currently knows how to drive the cache, invalidate it if any
> of the files involved in defining the profile are modified, etc. But
> it'd be nice if this functionality were exposed via a library that
> systemd could use so that it could compile (and cache) the policy if
> needed, it could load a cached policy if one exists and isn't stale.
>
AppArmomr does provide a library interface to the cache and loading,
it does not however provide a library interface to compiling policy.

man aa_policy_cache will give you documentation for
       aa_policy_cache - an opaque object representing an AppArmor policy
       cache

       aa_policy_cache_new - create a new aa_policy_cache object from a path

       aa_policy_cache_ref - increments the ref count of an aa_policy_cache
       object

       aa_policy_cache_unref - decrements the ref count and frees the
       aa_policy_cache object when 0

       aa_policy_cache_remove - removes all policy cache files under a path

       aa_policy_cache_replace_all - performs a kernel policy replacement of
       all cached policies

and man aa_kernel_interface

       aa_kernel_interface - an opaque object representing the AppArmor kernel
       interface for policy loading, replacing, and removing

       aa_kernel_interface_new - create a new aa_kernel_interface object from
       an optional path

       aa_kernel_interface_ref - increments the ref count of an
       aa_kernel_interface object

       aa_kernel_interface_unref - decrements the ref count and frees the
       aa_kernel_interface object when 0

       aa_kernel_interface_load_policy - load a policy from a buffer into the
       kernel

       aa_kernel_interface_load_policy_from_file - load a policy from a file
       into the kernel

       aa_kernel_interface_load_policy_from_fd - load a policy from a file
       descriptor into the kernel

       aa_kernel_interface_replace_policy - replace a policy in the kernel
       with a policy from a buffer

       aa_kernel_interface_replace_policy_from_file - replace a policy in the
       kernel with a policy from a file

       aa_kernel_interface_replace_policy_from_fd - replace a policy in the
       kernel with a policy from a file descriptor

       aa_kernel_interface_remove_policy - remove a policy from the kernel

       aa_kernel_interface_write_policy - write a policy to a file descriptor

the compile part will eventually come as a library but is far less useful
and systemd should just call the external policy compiler if policy is stale.

> Since different tools own different AppArmor policies (init scripts own
> /etc/apparmor.d/, snapd owns snapd policy, libvirt owns libvirt policy,
> docker owns docker policy, etc) this may need some effort to determine...