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.
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
object
all cached policies
and man aa_kernel_interface
interface for policy loading, replacing, and removing
an optional path
kernel
into the kernel
descriptor into the kernel
with a policy from a buffer
kernel with a policy from a file
kernel with a policy from 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 parser. conf apparmor will load/reload
> /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/
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.
>