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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063976
Title:
Apparmor breaking nsjail in AOSP
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2063976/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
