Comment 28 for bug 1679704

So I have been looking at this again, and have found a couple issues.

1. Where prlimit is concerned. AppArmor adds an addition restriction on when cap sys_resource is required. The CAP_SYS_RESOURCE capability is required if the target processes label does not match that of the caller.

Hence why libvirtd requires
  capability sys_resource,

in its profile.

The apparmor check should be broken down further as other ipc checks, but that should not have an effect here based on the peer= field. For the cap_sys_resource check the profile does not need an rlimit rule.

2. if stacking is used the denial message could be misleading as a denied message will be generated for each profile in the stack even if it was not a profile causing the denial.

In this case we should see duplicates of the above denial except with the profile= field changing. So one with libvurtd and another with some other process. With the currently available information this does not seem to be the problem.

3. The rawdata for the libvirtd profile does show the profile has CAP_SYS_RESOURCE permissions

4. It is the CAP_SYS_RESOURCE check that is failing. This check will only be triggered when using prlimit with a target having a different confinement than the setting task. Which is exactly what we see in the audit message.

There is a logic inversion bug in this path.

I have a test kernel building and will update when its ready