systemd sandboxing about apparmor.d HOT 2 CLOSED

Namespaces are fully confined unless switched explicitly (PUx, change_profile, etc). But, they are not fully compatible yet (all these attach_disconnected requirements and file_inherit problems). I can't tell more, but here's what I found: https://stackoverflow.com/questions/66295981/how-does-apparmor-handle-linux-kernel-mount-namespaces

As for NS reliability, I have them disabled on my systems because of wide attack surface of privilege escalation: https://madaidans-insecurities.github.io/linux.html#kernel

from apparmor.d.

Sandboxing and confinement are two different things... and you need both.

Conceptually a sandbox is a jail cell, a program has full access to its cell (its container). While a confined program it is like us in lockdown during COVID. It has access to a predefined list of resources but it is "free".

The challenge for sandboxing is to create a container that has the good shape (enough caps, mount, access...) while for confinement writing the profile is a pain.

In practice sandboxing is very powerful when a program does not access other program too much. For instance, in a server or a GUI app where the interactions are well defined and therefore it is easy to define a generic sandbox. While MAC is mostly used for core programs that have more interactions like systemd, dbus, polkit, Gnome... See the concepts section in the readme.

The end goal of this project is to prevent the execution of unconfined program. Therefore, at some point, sandbox program will also be confined.

from apparmor.d.