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 Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1679704 Title: libvirt profile is blocking global setrlimit despite having no rlimit rule Status in The Ubuntu-power-systems project: In Progress Status in apparmor package in Ubuntu: In Progress Bug description: Hi, 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. Symptom: [ 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 libvirt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1679704/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
