virt-manager fails to show virtual console: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS

Bug #1833040 reported by Didier Roche on 2019-06-17
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Medium
Christian Ehrhardt 

Bug Description

This bug is similar to https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1747442, but since latest libvirt 5.4.0-0ubuntu1 hit Eoan, it reappaerred.

It seems a new syscall is made by this version of libvirt, with the apparmor profile denying it:
juin 17 09:56:35 casanier audit[21675]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-257f9611-e750-4683-902a-79c3c45b66a9" pid=21675 comm="apparmor_parser"
juin 17 09:56:35 casanier audit[21694]: AVC apparmor="DENIED" operation="file_receive" profile="libvirt-257f9611-e750-4683-902a-79c3c45b66a9" pid=21694 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirtd"
juin 17 09:56:35 casanier libvirtd[1137]: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS
juin 17 09:56:35 casanier audit[21694]: AVC apparmor="DENIED" operation="file_receive" profile="libvirt-257f9611-e750-4683-902a-79c3c45b66a9" pid=21694 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirtd"
juin 17 09:56:35 casanier libvirtd[1137]: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS
juin 17 09:56:35 casanier audit[21694]: AVC apparmor="DENIED" operation="file_receive" profile="libvirt-257f9611-e750-4683-902a-79c3c45b66a9" pid=21694 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirtd"
juin 17 09:56:35 casanier libvirtd[1137]: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS

Thus, the apparmor profile needs to be updated so that a VM can start showing its console in virt-manager for instance.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: libvirt0 5.4.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-16.17-generic 5.0.8
Uname: Linux 5.0.0-16-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu3
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Jun 17 09:58:35 2019
InstallationDate: Installed on 2018-05-24 (388 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: libvirt
UpgradeStatus: Upgraded to eoan on 2019-01-08 (159 days ago)
modified.conffile..etc.libvirt.nwfilter.allow-arp.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/allow-arp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp-server.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/allow-dhcp-server.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/allow-dhcp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-incoming-ipv4.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/allow-incoming-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.allow-ipv4.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/allow-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.clean-traffic-gateway.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/clean-traffic-gateway.xml']
modified.conffile..etc.libvirt.nwfilter.clean-traffic.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/clean-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-ip-spoofing.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-mac-spoofing.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-spoofing.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-arp-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-multicast.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-ip-multicast.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-spoofing.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-broadcast.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-mac-broadcast.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-spoofing.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-l2-traffic.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-other-l2-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-rarp-traffic.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/no-other-rarp-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self-rarp.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/nwfilter/qemu-announce-self.xml']
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/qemu.conf']
modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: [Errno 13] Permission non accordée: '/etc/libvirt/qemu/networks/default.xml']

Related branches

Didier Roche (didrocks) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libvirt (Ubuntu):
status: New → Confirmed
Dimitri John Ledkov (xnox) wrote :

As a workaround I have created:
/etc/apparmor.d/local/abstractions/libvirt-qemu

with contents:
unix,

which allows doing anything/everything with sockets. It should be more fine-grained than that.

Thanks Didier and Dimitri!

I'll take a look at a more fine grained rule - but right now a few other blockers need to get out of the way first :-/

tags: added: libvirt-19.10
Changed in libvirt (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
assignee: nobody → Christian Ehrhardt  (paelzer)

As I assumed easily reproducible

[ 7152.173377] audit: type=1400 audit(1560925171.038:439): apparmor="DENIED" operation="file_r50-221da1d95974" pid=18422 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 "

Compared to other denies this is really rather low on extra qualifiers - I see why you just added "unix," for now :-/

We used to have this for the past few releases:
  unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd),

The peer detection is gone now, I have now good idea why, but essentially for libvirt 4.0 we have to trim the rule to
  unix (send, receive) type=stream addr=none,

Which still a rather (too) open rule.

Further I have realized that your systems (which are Eoan, while I'm eoan LXD on Bionic+HWE 4.18) actually detect a peer, but with the path changed.
- kernel 5.0.0-16 (Eoan) peer="libvirtd"
- kernel 4.18 (Bionic + HWE) no peer detected
- older libvirt peer=(label=/usr/sbin/libvirtd)

I started a discussion in #security
if nothing comes back I'll set jdstrand to CC anyway when submitting something upstream, maybe he has an idea why the peer detection was changed.

In a Eoan VM I can recreate your case (with peer = libvirt without path)

I was discussing with jjohansen, but we couldn't easily identify a apparmor related change.
I'd think we actually have two cases here:
- there was some libvirt change that slightly changed how this is called
  - in LXD+HWE kernel this leads to no peer detection at all - but that is an unsupported corner
    case anyway, and might even be good with a newer kernel like the one you have
  - in normal execution the peer detection changed from "/usr/sbin/libvirtd" to "libvirtd"
  - the latter might be depending on the kernel, so e.g. UCA backports might see the old one

Ha I found the change that triggered this and a partial cleanup:
Trigger: https://libvirt.org/git/?p=libvirt.git;a=commit;h=a3ab6d42
Partial cleanup: https://libvirt.org/git/?p=libvirt.git;a=commit;h=4ec3cf9a

Ok, the needed change is clear let me suggest it upstream.

This works as expected:
  unix (send, receive) type=stream addr=none peer=(label=libvirtd),

Submitted upstream, once accepted a fix in Eoan should be trivial
=> https://www.redhat.com/archives/libvir-list/2019-June/msg00722.html

Didier Roche (didrocks) wrote :

Thanks for keeping us posted Christian :)

Acked and Pushed upstream, prepping an Eoan upload.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 5.4.0-0ubuntu2

---------------
libvirt (5.4.0-0ubuntu2) eoan; urgency=medium

  * d/p/ubuntu-aa/lp-1833040-Add-openGraphicsFD-rule-for-named-profile.patch:
    avoid issues with remote screen connections like virt-manager due to
    apparmor changes in libvirt 5.1 (LP: #1833040)

 -- Christian Ehrhardt <email address hidden> Wed, 19 Jun 2019 14:34:54 +0200

Changed in libvirt (Ubuntu):
status: Triaged → Fix Released
John Johansen (jjohansen) wrote :

So

[ 7152.173377] audit: type=1400 audit(1560925171.038:439): apparmor="DENIED" operation="file_r50-221da1d95974" pid=18422 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 "

is really bothering me. This should not be possible. operation="file_r50-221da1d95974" does NOT exist, this looks like memory corruption. And several of the other fields that are missing would trigger AA_BUG.

Sadly I don't have this figured out yet.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers