running privileged applications out of home is dirty. But it is the
situation we are in with user namespaces and app images as well. Ubuntu
will not ship a profile for a privileged executable in the users home or
a writable location of an unprivileged user. As this can be leveraged to
by-pass the restriction, or it requires us to expand user mediation in
such a way that user writable locations with profiles defined become
privileged. Atm we are not adding addition restriction to the user. This
allows the user to define a profile that allows by-passing the
restriction. A user opting to create a profile in a user writable
location is less dangerous as the location becomes non-standard so it
becomes harder to exploit. It also requires the user to take a
deliberate privileged action to add the profile.
Generally for the nsjail profile an attachment like
@{HOME}/android-*/prebuilts/build-tools/linux-x86/bin/nsjail
is slightly better, but still not great. Atm it is very close to the
same, but there are improvements coming that will tighten @{HOME} to a
user specific kernel variable which will be better than /**.
The other way to handle this would be setting the security xattr and
using that as part of the attachment.
```
sudo setfattr -n security.apparmor -v nsjail
```
and define the profile as something like (you can make the path more
specific if you want).
```
profile nsjail /**/nsjail xattrs=(security.apparmor="nsjail")
flags=(unconfined) {
```
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2063976
Title:
Apparmor breaking nsjail in AOSP
Status in apparmor package in Ubuntu:
New
Bug description:
Build sandboxing in AOSP is broken after updating to 24.04 with the
following denials:
[ 182.439078] audit: type=1400 audit(1714265880.641:449): apparmor="AUDIT"
operation="userns_create" class="namespace" info="Userns create - transitioning
profile" profile="unconfined" pid=8514 comm="nsjail" requested="userns_create"
target="unprivileged_userns"
[ 182.439945] audit: type=1400 audit(1714265880.642:450): apparmor="DENIED"
operation="capable" class="cap" profile="unprivileged_userns" pid=8515
comm="nsjail" capability=6 capname="setgid"
[ 182.439972] audit: type=1400 audit(1714265880.642:451): apparmor="DENIED"
operation="mount" class="mount" info="failed mntpnt match" error=-13
profile="unprivileged_userns" name="/" pid=8515 comm="nsjail" flags="rw,
rprivate"
This seems to come from the following change earlier this year:
https://gitlab.com/apparmor/apparmor/-/commit/789cda2f089b3cd3c8c4ca387f023a36f7f1738a
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2063976/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
