[apparmor] Apparmor profile acting as in enforce mode when set to complain mode

[John Johansen]

On 11/9/24 03:26, mikolaj_archusr at tutamail.com wrote:
> Hello,

Hey
> I recently started experimenting with AppArmor and have successfully created profiles for several applications. However, I encountered an issue while profiling Steam. Specifically, Steam fails to launch when AppArmor is enabled. Below is the error output from Steam:

It would be helpful if you can include the following information
distro, release version, kernel version, apparmor_version.

> ```
> steam.sh[204656]: Running Steam on arch rolling 64-bit
> steam.sh[204656]: STEAM_RUNTIME is enabled automatically
> setup.sh[204732]: Steam runtime environment up-to-date!
> steam-runtime-check-requirements[206680]: W: Child process exited with code 1: bwrap: setting up uid map: Permission denied
> 
> steam.sh[204656]: Error: Steam now requires user namespaces to be enabled.
> 
> This requirement is the same as for Flatpak, which has more detailed
> information available:
> https://github.com/flatpak/flatpak/wiki/User-namespace-requirements <https://github.com/flatpak/flatpak/wiki/User-namespace-requirements>
> ```

yes flatpak does generally require user namespaces

> 
>  From the URL provided in the output, I quickly figured out It is an issue related to bubblewrap.
> 
yes, flatpak uses bubblewrap to setup its sandbox

> Below is the output of bwrap when it's profile is set to complain mode:
> ```
>   >> bwrap --bind / / --ro-bind /usr /usr --dev /dev --proc /proc --dir /tmp --unshare-user
> --unshare-net --unshare-pid /bin/bash --expose-pids
> bwrap: setting up uid map: Permission denied
> ```

setting the uid map requires root level privileges in the user namespace and apparmor is denying
the elevation of privileges in the user namespace

> 
> Here is the AppArmor profile I have configured for bwrap:
> ```
> abi <abi/4.0>,
> include <tunables/global>
> 
> profile bwrap /usr/bin/bwrap flags=(complain) {
>    userns,
> 
>    # Site-specific additions and overrides. See local/README for details.
>    include if exists <local/bwrap>
> }

Do have any DENIED or ALLOWED messages from apparmor in the logs? It is possible that
this profile is not being attached. If flatpak has a profile, its profile will
determine whether this profile gets used.

> ```
> 
> I also verified that `/proc/sys/kernel/unprivileged_userns_clone` is set to `1`.
> ```
>   >> cat /proc/sys/kernel/unprivileged_userns_clone
> 1
> ```

Do you have?
/proc/sys/kernel/apparmor_restrict_unprivileged_userns
/proc/sys/kernel/apparmor_restrict_unprivileged_unconfined

and what are their values?


My first guess was that you are on Ubuntu 24.04 or 24.10 but both and hitting
the user namespace restriction. See the following link

https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction

Ubuntu kernels afaik are the only ones with this enabled by default. But
then you should also have profiles already allowing flatpak and steam installs
to function.

Upstream kernels kernel can deny access to user namespaces or capabilities within
the user namespace if your application is already in a profile. So we need to
determine what your applications confinement is and what the specific denial
you are receiving is.

 From the above information I believe you are past the userns permission check
and failing on the capabilities check, but I can't be sure. Nor can am I
sure of what confinement flatpak/steam is under without further information.

> 
>  From `/sys/kernel/security/apparmor/profiles` I can see that `bwrap` is set to complain mode, so It should not be restricted in any way.
> I suspect this may be an issue with my configuration rather than a bug in AppArmor itself. If anyone has insights or suggestions for resolving this, I would greatly appreciate your help.

AppArmor attachment of profiles involves more than just the profile declaration.
Every profile gets to declare what it is designed to confine but that doesn't
actually determine if it will be attached to a given binary. The confinement of
the parent executable will determine what is done.

In the case of the parent executable being unconfined, the executable rule
is
   pix /**,

meaning use the best matching profile, and if there isn't one fallback and
inherit being unconfined. But if the parent profile has a different rule
then the declared profile attachment may not happen. Eg. the parent confinement
could have a rule like
   ix usr/bin/bwrap,

saying that when I run bubblewrap it will use my current confinement not
the declared profile.

So you need to introspect the actual running process to see what confinement
is being used on a given task. This can be done via looking at the security
context
   ps -Z
   pstree -Z
   ...



> Thank you in advance!