The audit log contains the following denials from libvirtd
apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="daemon-init" capability=17 capname="sys_rawio"
apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=39 capname="bpf"
apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=38 capname="perfmon"
Squelch the denials and allow the capabilities in the libvirtd
apparmor profile.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
---
I'm not really sure when these denials first started appearing, nor
have I noticed any problems they are causing. Likely I have not exercised
the affected functionality.
src/security/apparmor/usr.sbin.libvirtd.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/security/apparmor/usr.sbin.libvirtd.in b/src/security/apparmor/usr.sbin.libvirtd.in
index bf4563e1e8..928782b709 100644
--- a/src/security/apparmor/usr.sbin.libvirtd.in
+++ b/src/security/apparmor/usr.sbin.libvirtd.in
@@ -25,6 +25,9 @@ profile libvirtd @sbindir@/libvirtd flags=(attach_disconnected) {
capability fsetid,
capability audit_write,
capability ipc_lock,
+ capability sys_rawio,
+ capability bpf,
+ capability perfmon,
# Needed for vfio
capability sys_resource,
--
2.31.1
On Mon, Jun 7, 2021 at 6:34 PM Jim Fehlig <jfehlig@suse.com> wrote:
>
> The audit log contains the following denials from libvirtd
>
> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="daemon-init" capability=17 capname="sys_rawio"
> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=39 capname="bpf"
> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=38 capname="perfmon"
>
> Squelch the denials and allow the capabilities in the libvirtd
> apparmor profile.
>
> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
> ---
>
> I'm not really sure when these denials first started appearing, nor
> have I noticed any problems they are causing. Likely I have not exercised
> the affected functionality.
>
> src/security/apparmor/usr.sbin.libvirtd.in | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/security/apparmor/usr.sbin.libvirtd.in b/src/security/apparmor/usr.sbin.libvirtd.in
> index bf4563e1e8..928782b709 100644
> --- a/src/security/apparmor/usr.sbin.libvirtd.in
> +++ b/src/security/apparmor/usr.sbin.libvirtd.in
> @@ -25,6 +25,9 @@ profile libvirtd @sbindir@/libvirtd flags=(attach_disconnected) {
> capability fsetid,
> capability audit_write,
> capability ipc_lock,
> + capability sys_rawio,
> + capability bpf,
> + capability perfmon,
>
> # Needed for vfio
> capability sys_resource,
> --
> 2.31.1
>
>
The patch LGTM, but the title is confusing. Maybe the following?
"apparmor: Permit new capabilities required by libvirt"
Otherwise...
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
--
真実はいつも一つ!/ Always, there's only one truth!
On 6/7/21 5:43 PM, Neal Gompa wrote:
> On Mon, Jun 7, 2021 at 6:34 PM Jim Fehlig <jfehlig@suse.com> wrote:
>>
>> The audit log contains the following denials from libvirtd
>>
>> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="daemon-init" capability=17 capname="sys_rawio"
>> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=39 capname="bpf"
>> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=38 capname="perfmon"
>>
>> Squelch the denials and allow the capabilities in the libvirtd
>> apparmor profile.
>>
>> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
>> ---
>>
>> I'm not really sure when these denials first started appearing, nor
>> have I noticed any problems they are causing. Likely I have not exercised
>> the affected functionality.
>>
>> src/security/apparmor/usr.sbin.libvirtd.in | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/src/security/apparmor/usr.sbin.libvirtd.in b/src/security/apparmor/usr.sbin.libvirtd.in
>> index bf4563e1e8..928782b709 100644
>> --- a/src/security/apparmor/usr.sbin.libvirtd.in
>> +++ b/src/security/apparmor/usr.sbin.libvirtd.in
>> @@ -25,6 +25,9 @@ profile libvirtd @sbindir@/libvirtd flags=(attach_disconnected) {
>> capability fsetid,
>> capability audit_write,
>> capability ipc_lock,
>> + capability sys_rawio,
>> + capability bpf,
>> + capability perfmon,
>>
>> # Needed for vfio
>> capability sys_resource,
>> --
>> 2.31.1
>>
>>
>
> The patch LGTM, but the title is confusing. Maybe the following?
>
> "apparmor: Permit new capabilities required by libvirt"
Reading again, I agree it is poorly worded. I used your suggestion, but
s/libvirt/libvirtd/.
Regards,
Jim
On Tue, Jun 8, 2021 at 1:35 PM Jim Fehlig <jfehlig@suse.com> wrote:
>
> On 6/7/21 5:43 PM, Neal Gompa wrote:
> > On Mon, Jun 7, 2021 at 6:34 PM Jim Fehlig <jfehlig@suse.com> wrote:
> >>
> >> The audit log contains the following denials from libvirtd
> >>
> >> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="daemon-init" capability=17 capname="sys_rawio"
> >> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=39 capname="bpf"
> >> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=38 capname="perfmon"
> >>
> >> Squelch the denials and allow the capabilities in the libvirtd
> >> apparmor profile.
> >>
> >> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
> >> ---
> >>
> >> I'm not really sure when these denials first started appearing, nor
> >> have I noticed any problems they are causing. Likely I have not exercised
> >> the affected functionality.
> >>
> >> src/security/apparmor/usr.sbin.libvirtd.in | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/src/security/apparmor/usr.sbin.libvirtd.in b/src/security/apparmor/usr.sbin.libvirtd.in
> >> index bf4563e1e8..928782b709 100644
> >> --- a/src/security/apparmor/usr.sbin.libvirtd.in
> >> +++ b/src/security/apparmor/usr.sbin.libvirtd.in
> >> @@ -25,6 +25,9 @@ profile libvirtd @sbindir@/libvirtd flags=(attach_disconnected) {
> >> capability fsetid,
> >> capability audit_write,
> >> capability ipc_lock,
> >> + capability sys_rawio,
> >> + capability bpf,
> >> + capability perfmon,
> >>
> >> # Needed for vfio
> >> capability sys_resource,
> >> --
> >> 2.31.1
> >>
> >>
> >
> > The patch LGTM, but the title is confusing. Maybe the following?
> >
> > "apparmor: Permit new capabilities required by libvirt"
>
> Reading again, I agree it is poorly worded. I used your suggestion, but
> s/libvirt/libvirtd/.
>
Works for me.
--
真実はいつも一つ!/ Always, there's only one truth!
On 6/8/21 12:34 AM, Jim Fehlig wrote:
> The audit log contains the following denials from libvirtd
>
> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="daemon-init" capability=17 capname="sys_rawio"
> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=39 capname="bpf"
> apparmor="DENIED" operation="capable" profile="libvirtd" pid=6012 comm="rpc-worker" capability=38 capname="perfmon"
>
> Squelch the denials and allow the capabilities in the libvirtd
> apparmor profile.
>
> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
> ---
>
> I'm not really sure when these denials first started appearing, nor
> have I noticed any problems they are causing. Likely I have not exercised
> the affected functionality.
>
> src/security/apparmor/usr.sbin.libvirtd.in | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/security/apparmor/usr.sbin.libvirtd.in b/src/security/apparmor/usr.sbin.libvirtd.in
> index bf4563e1e8..928782b709 100644
> --- a/src/security/apparmor/usr.sbin.libvirtd.in
> +++ b/src/security/apparmor/usr.sbin.libvirtd.in
> @@ -25,6 +25,9 @@ profile libvirtd @sbindir@/libvirtd flags=(attach_disconnected) {
> capability fsetid,
> capability audit_write,
> capability ipc_lock,
> + capability sys_rawio,
> + capability bpf,
> + capability perfmon,
>
> # Needed for vfio
> capability sys_resource,
>
I remember somebody contacting me on IRC privately asking about
sys_rawio. IIRC I was told that 7.3.0 was okay and 7.4.0 started
requiring sys_rawio. But in my limited testing I don't see any failure
when I drop these caps. Anyway, the patch looks good to me.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal
© 2016 - 2026 Red Hat, Inc.