> To clarify, this is not something that can be solved upstream in
apparmor, and a profile can't be accepted due to the nature of the path
location?
correct, if it is a unprivileged user writable location it can't be
fixed entirely upstream. It is possible for us to ship a profile that is
To clarify, this is not something that can be solved upstream in
apparmor, and a profile can't be accepted due to the nature of the path
location?
I'm really trying to avoid a situation where we need to add additional
instructions after syncing AOSP just for Ubuntu users.
One idea for this was
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
Thanks, I took a look at creating a profile for nsjail, but I'm a bit
confused on how to associate it with the app?
Because nsjail is a prebuilt in AOSP's source code that means it could be
litteraly anywhere on the user's system, e.g:
Commit 789cda2f089b3cd3c8c4ca387f023a36f7f1738a only controls the
behavior of unprivileged user namespace mediation.
With the unprivileged_userns profile loaded, when a user namespace is
created by an unprivileged unconfined application the task will be
transitioned into the unprivileged_userns
