[apparmor] RFC: draft proposal for enabling AppArmor by default in Debian

[John Johansen]

On 08/04/2017 12:05 PM, John Johansen wrote:

<< snip >>

>>
>> I am not aware of any plans for Flatpak to rely on an LSM: it's all
>> done with namespaces, seccomp and NO_NEW_PRIVS. Flatpak is entirely
>> unprivileged, and bubblewrap doesn't retain CAP_MAC_ADMIN (it's setuid
>> on Debian and RHEL, but is designed to be unnecessary to make setuid on
>> distributions like Fedora and Ubuntu that allow unprivileged userns
>> creation).
>>
>>> In any case, it is my understanding that this is not an either/or
>>> situation: one can perfectly well use this tools with
>>> AppArmor enabled.
>>
> it is possible, but there are currently issues
To clarify, the issues revolve around mount namespaces, and no_new_privs.


no_new_privs due to a discussion by the kernel developers to limit
the lsm when it is applied. For most uses this isn't a problem, apparmor
confinement can be applied just fine. However it does apparmor from
transitioning policy when no-new-privs is applied. Basically no-new-privs
can cause restrictions on apparmor policy.

The mount namespace issue, is covered some below.

> 
>> Mount namespaces interact poorly with a path-based LSM like AppArmor.
>> With the way in which Bubblewrap currently uses pivot_root() in its
>> private mount namespace, a Flatpak app will currently appear to
>> AppArmor to be accessing filenames like /newroot/app/bin/openarena,
>> /newroot/usr/lib/libGL.so.1 and /newroot/home/smcv/, and it does not
>> appear to be possible to disambiguate which root we are operating in.
>>
>> (I would love to be proved wrong on this!)
>>
> This is a real problem currently. We are working on fixing it, but its
> not just an apparmor issue. On the apparmor end of things, apparmor
> now supports policy namespaces and stacking, allowing for policy
> within a container to expect and be fine with a different root. The
> delegation and inode labeling support are still a wip and will
> provide another avenue for dealing with some of the issues.
> 
The policy namespaces work well for policy inside a container situations,
eg. having an lxd container load its own system policy and have it apply,
separate from the host system policy.

They do not currently fix the cross mount namespace issues that Simmon
brought up.  Where the system policy is authored from the pov of a
different mount namespace.

If you are interested in the fixes for these, we can poke at the
solutions more but I don't think they will help this discussion
beyond saying fixes for the issues are coming at some point in the
future. I am not willing to commit to a time frame atm as we are
trying hard to take an upstream first approach that will benefit
everyone.

> However there The kernel currently doesn't make it possible at the
> LSM level to properly manage namespaces.
> 
> There is a micro-conference at plumbers and bof at LSS this year to
> work on the problems of namespacing and the LSM. Hopefully we can
> fix these issues soon.
>