[apparmor] AVC apparmor="ALLOWED" operation="exec" info="no new privs" error=-1

[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.

[Mikhail Morfikov]

Hello,

Post by 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
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
/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.
http://paste.opensuse.org/12822406
This topic was discussed on IRC yesterday, so let me quote the relevant
<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?

[John Johansen]

Post by Mikhail Morfikov

Hello,

Post by 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
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
/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.
http://paste.opensuse.org/12822406
This topic was discussed on IRC yesterday, so let me quote the relevant
<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.