roddhjav / apparmor.d

Full set of AppArmor profiles (~ 1500 profiles)
https://apparmor.pujol.io
GNU General Public License v2.0
439 stars 40 forks source link

systemd sandboxing #83

Closed beroal closed 6 months ago

beroal commented 1 year ago

Recently systemd acquired a capability to isolate its services using kernel namespaces. An example is service file /usr/lib/systemd/system/tor.service shipped with Arch Linux. AFAIK, kernel namespaces are strictly more powerful than AppArmor. For example, we can give a separate /tmp directory to every process using kernel namespaces.

What is the interaction between AppArmor profiles and systemd service files with sandboxing? Does systemd sandboxing obsolete AppArmor profiles? Should we use AppArmor profiles and systemd sandboxing together?

nobody43 commented 1 year ago

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

roddhjav commented 1 year ago

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.