[apparmor] Toward cooperation between bubblewrap and AppArmor

John Johansen john.johansen at canonical.com
Mon Sep 27 06:24:29 UTC 2021


On 9/22/21 12:08 PM, Forest wrote:
> A discussion has come up about getting bubblewrap and AppArmor to cooperate.
> One use case would be allowing Steam (which recently started launching games
> in a bwrap container) to work in AppArmor-restricted environments like LXC.
> 
> I think some perspective from AppArmor maintainers would be valuable there:
> 
> https://github.com/containers/bubblewrap/issues/362
> 

So yes AppArmor currently has issues with mount namespaces and pivot_root. It
does play better with chroot at least from a system policy perspective, but
chroot has its own issues. Depending on how pivot_root is used the effects
range from minor to completely breaking its security. It is something we have
been working on fixing, but regrettably it has been extremely slow going.

Currently the best that can be done has pretty much been covered either
running unconfined or under a very loose profile. stgraber has already
covered the lxc/d side of things so I will just address the apparmor side.


There are two issues here a conflict between how the container/bubblewrap
and apparmor trying to protect the container/system, and how apparmor currently
handles namespacing and pivot_root.

Techniques like namespacing, pivot_root, and no_new_privs all present
difficulties to an LSM because not all the needed interfaces are present,
and there is a mismatch between how the feature was designed and how the
LSM (not necessarily just apparmor) generally works.

Eg. if the container or bubble wrap want to use a read only bind mount
to protect a file then apparmor policy would have to allow that where
natively it wouldn't and it would just enforce that the file is readonly
as part of its policy.

This is a general issue encountered when differing security mechanisms
with overlap are being applied. So its not just a bubblewrap/apparmor
issue, we run into issues when stacking apparmor and selinux or smack, or
even something as simple as apparmor and yama. Some modification to either
one or both of the conflicting mechanism will be needed.

To help address this problem we are working on several improvements on the
apparmor side. Without getting into too much detail there are improvements
to handling of namespaces and pivort_root, no_new_privs, object delegation,
and policy conditionals.

Policy conditionals are probably the place where apparmor and bubblewrap
can cooperate the most, as they will allow policy to be more easily adapted
to different situations. We certainly could use help in defining what rule
changes and conditionals would be beneficial for bubblewrap. As well as
input on any potential apis for tweaking them.



More information about the AppArmor mailing list