On 11/9/24 03:26, mikolaj_arch...@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!
