AppArmor profile enforcement unconditionally skipped in rootless mode

[phil-02]

Summary

pkg/apparmor/internal/supported/supported.go returns "AppArmor is not supported on rootless containers" unconditionally when unshare.IsRootless() is true. The comment in apparmor_linux.go justifies this as "requires root", but aa_change_onexec() operates by writing to /proc/self/attr/exec — this does not require elevated privileges and works from unprivileged processes on kernels that support it.

The result is that podman info reports apparmorEnabled: false on rootless systems with AppArmor fully operational, and apparmor_profile in containers.conf is silently ignored.

Affected files

• pkg/apparmor/internal/supported/supported.go — IsSupported() hard-gates on IsRootless()
• pkg/apparmor/apparmor_linux.go — lines 86–87, 152–153, 265–269

Comparison with Docker

Docker applies docker-default to all containers automatically. Switching to rootless Podman silently removes this layer without warning.

Proposed fix

Replace the unconditional IsRootless() guard with a runtime capability probe:

1. Attempt aa_change_onexec() with a known-loaded profile in a test exec
2. If it succeeds, AppArmor is usable in this rootless context
3. If it returns EPERM/EACCES, fall back gracefully and log a clear warning

This respects kernel-level restrictions (apparmor_restrict_unprivileged_unconfined) without hardcoding a blanket "rootless = no AppArmor" rule. The existing verifierImpl interface already provides the right abstraction for mocking this in tests.

Environment

• containers/common: 0.57.4
• Kernel: 6.17.0 (Ubuntu)
• apparmor_restrict_unprivileged_unconfined: 0
• apparmor_restrict_unprivileged_userns: 1

[phil-02]

Note: This is a revival of containers/common#958 (2022), which was closed after a maintainer requested a PR but none was submitted. The prior issue included a working proof-of-concept diff from @kernelmethod. Flagging the history here so reviewers have the context.

[phil-02]

Tagging recent contributors to the AppArmor code who may have relevant context:

• @mtrmac (current maintainer, recent commits to common/pkg/apparmor)
• @NeilW (updated AppArmor profile for v4.0.0, May 2024)
• @terencehonles (updated AppArmor profile to allow signal sending, Nov 2024)

The 2022 maintainer note was "none of the core maintainers use AppArmor" — that may no longer be true given the above activity.

[Luap99]

That is already tracked in containers/podman#15874

The answer is still the same none for the current maintainers use or care much about apparmor.
The main issue is that creating a profile and loading that into apparmor needs root AFAIK, just applying a profile that already is load does not. So IMO the way apparmor is handled today is wrong and it should be done more like selinux where the profile is shipped as part of the package and loaded by that and all podman does is to apply it then which should work as and rootless.

Also please note https://github.com/containers/podman/blob/main/LLM_POLICY.md