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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
