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
Hence why libvirtd requires
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
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
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
libvirt profile is blocking global setrlimit despite having no rlimit
To manage notifications about this bug go to:
ubuntu-bugs mailing list