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
  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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.

  libvirt profile is blocking global setrlimit despite having no rlimit

Status in The Ubuntu-power-systems project:
  In Progress
Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  while debugging bug 1678322 I was running along apparmor issues.
  Thanks to jjohansen we debugged some of it and eventually I was asked to 
report to a bug.

  [ 8976.950635] audit: type=1400 audit(1491310016.224:48): apparmor="DENIED" 
operation="setrlimit" profile="/usr/sbin/libvirtd" pid=10034 comm="libvirtd" 
rlimit=memlock value=1610612736

  But none of the profiles has any rlimit statement in it:
  $ grep -Hirn limit /etc/apparmor*
  /etc/apparmor.d/sbin.dhclient:58:  # such, if the dhclient3 daemon is 
subverted, this effectively limits it to
  /etc/apparmor.d/abstractions/ubuntu-helpers:16:# Limitations:
  /etc/apparmor.d/abstractions/ubuntu-helpers:64:  # in limited libraries so 
glibc's secure execution should be enough to not
  /etc/apparmor.d/cache/.features:13:rlimit {mask {cpu fsize data stack core 
rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime

  The profile contains a child profile which makes reading the dumps a bit 
painful, but I'll attach them anyway for you to take a look.
  To "recreate" if needed check out bug 1678322 - TL;DR hot-add some VFs via 

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to