AppArmor and SELinux on openSUSE: podman gotchas

Which one do I have?

In February 2025 Tumbleweed made SELinux in enforcing mode the default for new installations; existing installations keep AppArmor, and the installer still lets you pick AppArmor (openSUSE News: Tumbleweed Adopts SELinux as Default). So two Tumbleweed machines can differ, and many forum answers are older than the switch. Check your own system before you follow one:

cat /sys/kernel/security/lsm               # contains selinux or apparmor
getenforce                                 # SELinux: Enforcing, Permissive or Disabled
sudo aa-status                             # AppArmor: loaded profiles (package apparmor-utils)

A Tumbleweed laptop that runs AppArmor, and a Fedora container running on it:

$ cat /sys/kernel/security/lsm
lockdown,capability,landlock,yama,apparmor,bpf,ima,evm
# inside the Fedora 44 container
$ ls /sys/fs/selinux >/dev/null 2>&1 && echo selinuxfs present || echo 'no selinuxfs: host kernel runs AppArmor'
no selinuxfs: host kernel runs AppArmor

SELinux: volumes and :Z

SELinux gives every file a label, and containers may only touch files labelled for containers. A folder you created in your home has a home label, so the container gets "permission denied" even though the Unix permissions are fine. The fix is a volume option:

[Container]
Volume=%h/appdata/whoami:/data:Z           # private: only this container uses it
Volume=%h/media:/media:z                   # shared: several containers use it

• :Z relabels the folder for this one container. Another container cannot use it any more.
• :z relabels it for all containers to share.
• %h is the user's home directory, filled in by systemd.

ls -Z ~/appdata                            # container_file_t after a :Z mount

Named podman volumes (Volume=whoami-data:/data) are labelled correctly from the start; only bind mounts of existing folders need the option.

SELinux: reading denials

Denials are logged as AVC messages. Reading them needs root:

sudo ausearch -m AVC -ts recent            # when auditd runs (package audit)
sudo journalctl -b -g avc                  # otherwise, from the journal
sudo setenforce 0                          # permissive: log but allow, for a quick test
sudo setenforce 1                          # and back to enforcing, right away

If the problem disappears in permissive mode, SELinux is the cause: fix the label and go back to enforcing. setenforce does not survive a reboot, which is a feature here. On a Cockpit server, the SELinux page (package cockpit-selinux) lists the same denials with suggested fixes. The journalctl command builder helps narrow the journal to one boot or time window.

AppArmor and podman

Whether a container is confined at all depends on your setup: which module the host runs, the policy packages installed (container-selinux for SELinux; podman's AppArmor profile is called container-default, set by apparmor_profile in containers.conf(5)), and whether podman runs rootless or as root. Do not assume; check it on your own machine. On this Tumbleweed laptop, with AppArmor active in the kernel and the parser installed, rootless podman reports AppArmor as off and the container process runs unconfined (rootful podman was not tested here, it needs root):

$ cat /sys/module/apparmor/parameters/enabled
Y
$ podman info --format 'apparmor={{.Host.Security.AppArmorEnabled}} selinux={{.Host.Security.SELinuxEnabled}}'
apparmor=false selinux=false
$ podman run --rm registry.fedoraproject.org/fedora:latest cat /proc/self/attr/current
unconfined

Run the same three commands on your server. unconfined means AppArmor is not what blocks that container; a profile name followed by (enforce) means it is confined. Where a profile applies, it restricts things like mounting inside the container, not reading your bind mounts, so everyday services seldom hit it. When one does, the denial is in the kernel log:

sudo journalctl -k -g 'apparmor="DENIED"'

For a container that genuinely needs more (rare for home services), test with PodmanArgs=--security-opt apparmor=unconfined in the quadlet, and keep it only if you understand why that container needs it. Plain permission errors on an AppArmor system are usually Unix permissions or user namespace mapping; see the rootless podman guide and the file permissions guide.

Common mistakes

Frequently asked questions