Comment 3 for bug 2063976

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) {
```