[apparmor] question about "no new privs"

[John Johansen]

On 11/3/18 8:08 AM, Mikhail Morfikov wrote:
> I can't really figure out what apparmor wants from me in the following message:
> 
not surprising, no-new-privs is a pita and what is needed will depend on your
kernel version and what you are trying to do. The nnp restrictions are not
something we wanted but something forced on LSMs. However nnp has become
such a problem that LSMs are now having to incorporate an override which was
explicitly disallowed originally.

> kernel: [61380.312237] audit: type=1400 audit(1541256918.026:2604):
> apparmor="DENIED" operation="exec" info="no new privs" error=-1
> profile="opt-google-chrome-chrome" name="/usr/bin/xdg-desktop-menu" pid=115118
> comm="TaskSchedulerFo" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
> target="xdg-desktop-menu"
> 
> I have an external profile for /usr/bin/xdg-desktop-menu and also I use the
> following rule in the opt-google-chrome-chrome profile:
> 
>   /usr/bin/xdg-desktop-menu rPUx,
> 
> So what apparmor rule is able to fix that message?
> 

At the moment none. Apparmor is blocked from doing any profile transitions
that aren't provably the same or a reduced set of permissions.

Since nnp apparmor has had only one case where a domain transition was
guarenteed to be allowed.  That is unconfined -> profile since that is
always a reduction in permissions.

With 4.13 when stacking support landed, stacking transitions were allowed
as each new addition to the stack results in a guaranteed reduction in
permissions.

4.18 gained the ability to save off the confinement at the time that nnp
is set and use that to check that permissions due to a transition are
always a subset. This is more flexible than 4.13 and allows containers
to transition their profiles while the system profile remains fixed.

We are hoping to land a nnp override in 4.21 (it wasn't quite ready
for 4.20) which is what you will need for your use case.