How Does Apparmor Handle Linux-Kernel Mount Namespaces

How does AppArmor handle Linux-kernel mount namespaces?

I would say that AppArmor is partially linux kernel mount namespace aware.I think the attach_disconnected flag in apparmor is an indication that apparmor knows if you are in the main OS mount namespace or a separate mount namespace.

The attach_disconnected flag is briefly described at this link (despite the warning at the top of the page claiming to be a draft):https://gitlab.com/apparmor/apparmor/-/wikis/AppArmor_Core_Policy_Reference

The following reference, from a ubuntu apparmor discussion, provides useful and related information although not directly answering your question.https://lists.ubuntu.com/archives/apparmor/2018-July/011722.html

The following references, from a usenix presentation, provides a proposal to add security namespaces to the Linux kernel for use by frameworks such as apparmor. This does not directly show how / if apparmor currently uses kernel mount namespaces for decision making, but it's related enough to be of interest.https://www.usenix.org/sites/default/files/conference/protected-files/security18_slides_sun.pdf https://www.usenix.org/conference/usenixsecurity18/presentation/sun

I don't know if my response here is complete enough to be considered a full answer to your questions, however I don't have enough reputation points to put this into a comment. I also found it difficult to know when the AppArmor documentation meant "apparmor policy namespace" vs "linux kernel mount namespace", when the word "namespace" was specified alone.

AppArmor: How to block pid=host container with CAP_SYS_ADMIN/CAP_SYS_CHROOT from reading (some) host files?

An ingrained restriction of AppArmor's architecture is that in case of filesystem resources (files, directories) it mediates access using the access path. While AppArmor uses labeling, as does SELinux, AppArmor derives only implicit filesystem resource labels from the access path. In contrast, SELinux uses explicit labels which are stored in the extended attributes of files on filesystems supporting POSIX extended attributes.

Now, the access path always is the path as seen in the caller's current mount namespace. Optionally, AppArmor can take chroot into account. So the answer to the second question item is: AppArmor "ignores" mount namespaces and just takes the (access) path. It does not translate the bind mounts, as far as I understand (there's nowhere any indication to be seen it would do).

As for the first question item: in general "no", due to AppArmor mediating access path (labels), not file resource labels. A limited access restriction is possible when accepting that there won't be any access path differentiation between what's inside a container and what's in the host outside the container (same for what's inside other containers). This is basically what Docker's default container AppArmor profile does: restricting all access to a few highly sensitive /proc/ entries and restricting to read-only access for many other /proc/ entries.

But blocking access to certain host file access paths always comes with the danger of blocking the same access path for a perfectly valid use inside a container (different mount namespace), so this requires great care, lots of research and testing, as well as the constant danger of things breaking in the next update of a container. AppArmor seems to not be designed for such usecases.

Related Topics