On 10/07/2017 10:34 AM, Mikhail Morfikov wrote: > On 2017-10-07 18:26, Christian Boltz wrote: >> Hello, >> >> Am Samstag, 7. Oktober 2017, 17:34:45 CEST schrieb Mikhail Morfikov: >>> After updating the kernel from 4.12 -> 4.13, some of my programs >>> stopped working, even though they have profiles in the "complain >>> mode". Here's an example of a message that appears in the system log: >>> >>> AVC apparmor="ALLOWED" operation="exec" info="no new privs" error=-1 >>> profile="/bin/app_1" name="/bin/app_2" pid=60616 comm="app_1" >>> requested_mask="x" denied_mask="x" fsuid=104 ouid=0 >>> target="/bin/app_2" >>> >>> According to this log, app_1 has its profile and it wanted to execute >>> app_2. The app_1 profile has the following rule: >>> >>> /bin/app_2 rPUx, >>> >>> Before upgrading the kernel, everything was fine, but now (even in the >>> complain mode), the app doesn't work well -- it simply stopped >>> working at all, and only removing the profiles can make it work >>> again. >>> >>> So what is wrong in this case? It has the permission to execute the >>> app_2, but it looks like that it doesn't work anymore. >> >> You probably have NoNewPrivileges=true in the systemd unit starting >> your service, and due to a change in the kernel, this also means it no >> longer allows switching to another profile. > Actually I don't have that, but maybe something implies it. > >> >> The easiest (and unfortunately less secure) workaround is not to use >> NoNewPrivileges if you need to switch to another profile. >> >> You could also patch that unfortune restriction away: >> http://paste.opensuse.org/12822406 >> >> >> This topic was discussed on IRC yesterday, so let me quote the relevant >> lines (slightly shortened) with some more details: >> >> <jjohansen> so the long term solution is for us come up with a scheme to >> lock the profiles in a stack that existed at the point of no-new- >> privs and then allow the rest in the stack to transition >> <jjohansen> so we have a pseudo plan for dealing with it but the devil >> is in the details (or implementation) >> <jjohansen> sadly atm you just can't have no-new-privs and profile >> transitions, that was something established by Linus >> <jjohansen> he didn't want/believe that LSMs should be able to >> "override" the tasks decision to lock down privilege changes >> <jjohansen> the LSMs have made arguments for being able to continue to >> reduce privs, and selinux just landed something to that effect >> >> >> Regards, >> >> Christian Boltz >> >> >> > I think I'll change my profiles to "fix" this issue, but if I understand > correctly, now all "PUx" and "Cx -> ..." has to be replaced with "ix" (+ > appropriate rules), right? >
yes once a task is under no new privs it is not allowed change its profile and potentially increase its privileges. There is one exception which is the unconfined state, since any profile transition is a reduction of privileges. So you are left with two potential transitions at the moment ix (inherit the current confinement) and stacking. Stacking is probably not what you want in that it keeps the current confinement and adds additional restrictions on top. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
