AppArmor denies access to /sys/block/*/queue/max_segments

Bug #1729626 reported by Martin Pitt
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Since Cockpit's "ubuntu stable" VM image got updated from Ubuntu 17.04 to 17.10, the libvirt tests now cause several instances of this AppArmor denial:

Nov 02 10:19:28 unassigned-hostname audit[1347]: AVC apparmor="DENIED" operation="open" profile="libvirt-7d476386-ebe3-46fc-b6fc-3afcf7e4346f" name="/sys/devices/pci0000:00/0000:00:02.0/virtio0/host2/target2:0:2/2:0:2:0/block/sda/queue/max_segments" pid=1347 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0

It does not actually break anything, but QEMU might use this for some optimizations? Reading this kind of hardware information from /sys seems harmless and useful enough to allow it in the profile.

Note: This seems to be a race condition, I cannot trivially reproduce it locally. Thus the extra Apport information here does not contain the violation. But I attach the journal from an instance that does.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: libvirt-daemon 3.6.0-1ubuntu5
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3
Architecture: amd64
Date: Thu Nov 2 11:11:02 2017
SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Martin Pitt (pitti) wrote :
tags: added: apparmor
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Qemu function hdev_get_max_segments reads this.
Access is to: /sys/dev/block/%u:%u/queue/max_segments with O_RDONLY
So yeah, the rule "/sys/dev/block/*/queue/max_segments r," should be good.

This is since qemu 2.9:
commit 9103f1ceb46614b150bcbc3c9a4fbc72b47fedcc
Author: Fam Zheng <email address hidden>
Date: Wed Mar 8 20:08:14 2017 +0800

    file-posix: Consider max_segments for BlockLimits.max_transfer

This is a fix for a rare bug, that due to the rule does not yet "fix" it.
Prio is low enough to not need any SRU, but it shall be fixed.

I'll create a fix to the upstream apparmor profiles and get them back on next merge.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

This always runs when a real disk is used, so add something like the following to your guest xml in libvirt:
    <disk type='block' device='disk'>
        <driver name='qemu' type='raw'/>
        <source dev='/dev/sdb'/>
        <target dev='vdc' bus='virtio'/>
    </disk>

And you get:
[954547.646002] audit: type=1400 audit(1509697037.925:33): apparmor="DENIED" operation="open" profile="libvirt-98160a65-f0e0-4bec-9b22-8573950cfb0e" name="/sys/devices/pci0000:00/0000:00:01.0/0000:03:00.0/host0/port-0:3/end_device-0:3/target0:0:2/0:0:2:0/block/sdb/queue/max_segments" pid=30375 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0
[954547.646052] audit: type=1400 audit(1509697037.925:34): apparmor="DENIED" operation="open" profile="libvirt-98160a65-f0e0-4bec-9b22-8573950cfb0e" name="/sys/devices/pci0000:00/0000:00:01.0/0000:03:00.0/host0/port-0:3/end_device-0:3/target0:0:2/0:0:2:0/block/sdb/queue/max_segments" pid=30375 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0

The suggested rule doesn't apply, as that is a symlink that is not traversed but directly opened:
  /sys/dev/block/*/queue/max_segments r,

Instead this works:
 /sys/devices/**/block/*/queue/max_segments

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
tags: added: libvirt-18.04
Changed in libvirt (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

If upstreaming works as planned that will be picked up on next merge.

Revision history for this message
Martin Pitt (pitti) wrote :

Nice work, thanks Christian!

Revision history for this message
Knickers Brown (metta-crawler) wrote :

This also happens if the VM host is storing guests in LVM not only "real disks". Example:
...
<source dev='/dev/vg0/lv0'/>
...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Yep, any "block device" essentially.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (13.5 KiB)

This bug was fixed in the package libvirt - 4.0.0-1ubuntu1

---------------
libvirt (4.0.0-1ubuntu1) bionic; urgency=medium

  * Merged with Debian unstable (4.0)
    This closes several bugs:
    - Error generating apparmor profile when hostname contains spaces
      (LP: #799997)
    - qemu 2.10 locks files, libvirt shared now sets share-rw=on (LP: #1716028)
    - libvirt usb passthrough throws apparmor denials related to
      /run/udev/data/+usb (LP: #1727311)
    - AppArmor denies access to /sys/block/*/queue/max_segments (LP: #1729626)
    - iohelper improvements to let bypass-cache work without opening up the
      apparmor isolation (LP: #1719579)
    - nodeinfo on s390x to contain more CPU info (LP: #1733688)
    - Upgrade libvirt >= 4.0 (LP: #1745934)
  * Remaining changes:
    - Disable libssh2 support (universe dependency)
    - Disable firewalld support (universe dependency)
    - Disable selinux
    - Set qemu-group to kvm (for compat with older ubuntu)
    - Additional apport package-hook
    - Modifications to adapt for our delayed switch away from libvirt-bin (can
      be dropped >18.04).
      + d/p/ubuntu/libvirtd-service-add-bin-alias.patch: systemd: define alias
        to old service name so that old references work
      + d/p/ubuntu/libvirtd-init-add-bin-alias.patch: sysv init: define alias
        to old service name so that old references work
      + d/control: transitional package with the old name and maintainer
        scripts to handle the transition
    - Backwards compatible handling of group rename (can be dropped >18.04).
    - config details and autostart of default bridged network. Creating that is
      now the default in general, yet our solution provides the following on
      top as of today:
      + autostart the default network by default
      + do not autostart if subnet is already taken (e.g. in guests).
    - d/p/ubuntu/Allow-libvirt-group-to-access-the-socket.patch: This is
      the group based access to libvirt functions as it was used in Ubuntu
      for quite long.
      + d/p/ubuntu/daemon-augeas-fix-expected.patch fix some related tests
        due to the group access change.
    - ubuntu/parallel-shutdown.patch: set parallel shutdown by default.
    - d/p/ubuntu/enable-kvm-spice.patch: compat with older Ubuntu qemu/kvm
      which provided a separate kvm-spice.
    - d/p/ubuntu/ubuntu-libxl-qemu-path.patch: this change was split. The
      section that adapts the path of the emulator to the Debian/Ubuntu
      packaging is kept.
    - d/p/ubuntu/ubuntu-libxl-Fix-up-VRAM-to-minimum-requirements.patch: auto
      set VRAM to minimum requirements
    - d/p/ubuntu/xen-default-uri.patch: set default URI on xen hosts
    - Add libxl log directory
    - libvirt-uri.sh: Automatically switch default libvirt URI for users on
      Xen dom0 via user profile (was missing on changelogs before)
    - d/p/ubuntu/apibuild-skip-libvirt-common.h: drop libvirt-common.h from
      included_files to avoid build failures due to duplicate definitions.
    - Update README.Debian with Ubuntu changes
    - Convert libvirt0, libnss_libvirt and libvirt-dev to multi-arch.
    - Enable some additional features on ppc...

Changed in libvirt (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.