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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1679704

Title:
  libvirt profile is blocking global setrlimit despite having no rlimit
  rule

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1679704/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to