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
> what we really want it to do.
> 
yes this is a problem, generally we have been taking the approach that
if the packaging drops the profile in the apparmor.d/ directory or other
directories set in /etc/apparmor/parser.conf apparmor will load/reload
it.

If they choose to store policy in another location (snappy, lxd, ...)
they are responsible for loading/managing that part of the policy.

Basically if you want apparmor to manage/load the policy it needs to
know where it is. Otherwise you are on your own.

> I hope this helps. Thanks.
>