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 - 2024 Red Hat, Inc.