Apparmor profile does not authorize access to shared filesystems

[Simon Déziel]

Adding a filesystem share to a guest does not translate in the required Apparmor access rules in the guest profile.

After adding the following to the guest definition :

    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/home/simon/9p'/>
      <target dir='/mnt/9p'/>
    </filesystem>

Accessing the 9p filesystem in the guest gives this error in the host :

Feb 29 18:25:40 simon-laptop kernel: [35709.852192] type=1400 audit(1330557940.265:104): apparmor="DENIED" operation="open" parent=1 profile="libvirt-deab2b00-05e4-9456-3d52-ec3c74f68083" name="/home/simon/9p/" pid=24732 comm="kvm" requested_mask="r" denied_mask="r" fsuid=114 ouid=114

A (not recommended) workaround it to add this to the /etc/apparmor.d/libvirt/libvirt-<UUID> policy :

  "/home/simon/9p/" rwkl,
  "/home/simon/9p/**" rwkl,

Ideally, virt-aa-helper would be aware of those 9p filesystems and should generate the appropriate ruleset.

$ lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10

$ apt-cache policy libvirt-bin
libvirt-bin:
  Installed: 0.9.2-4ubuntu15.2
  Candidate: 0.9.2-4ubuntu15.2
  Version table:
 *** 0.9.2-4ubuntu15.2 0
        500 http://archive.ubuntu.com/ubuntu/ oneiric-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.2-4ubuntu15 0
        500 http://archive.ubuntu.com/ubuntu/ oneiric/main amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: libvirt-bin 0.9.2-4ubuntu15.2
ProcVersionSignature: Ubuntu 3.0.0-16.29-generic 3.0.20
Uname: Linux 3.0.0-16-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Wed Feb 29 18:23:43 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
ProcEnviron:
 LANGUAGE=en_CA:en
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)

[Serge Hallyn (serge-hallyn)]

Hi Jamie,

I only assigned this bug to quickly seek your advice. Does this seem like something which might have an easy solution?

[Jamie Strandboge (jdstrand)]

Not an easy solution no. The security driver needs to have hooks for '9p'. If the qemu driver already has it, then it isn't hard to add it to the apparmor driver. If not, then the qemu driver, the DAC driver, the selinux driver and the apparmor driver all need to be updated (though that is an upstream bug-- they might not fix apparmor, but they would fix all the others (and maybe apparmor)).

[Martijn Lievaart (j-launchpad-net-rtij-nl)]

Bug still present on 12.10, exactly like described above.

[billhuey (bill-huey)]

Just adding my view on the matter, this is a somewhat critical bug in that the only manner in which you can shared a file system is with an NFS mount. That puts both memory pressure on the guest and host in that buffers must be replicated across both domains where guests must buffer the file system data as well as the host. Growing the guest will take away memory needed by the host for good file system performance.

This could be a severe performance issue in certain systems and is certainly rather bad for heavier VM workloads

[billhuey (bill-huey)]

Last comment for now, this is present on 13.04

[Fiona Klute (fiona-klute)]

The bug is still present in 13.10.

[Simon Déziel (sdeziel)]

In LP: #1285995, Hiroshi Miura proposed a fix that generates the missing Apparmor rules.