"Failed to create chardev" due to apparmor DENIED execute of "/usr/lib/pt_chown"

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect BUGNUMBER
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Please show the xml for the failing domain.

Serge, there is no XML since the failure occurred during the creation by virt-manager and it doesn't save a domain XML file if there's a creation failure, which was why I had to show the log outputs.

Thanks - this is odd, as neither libvirt nor qemu should be calling pt_chown. I cannot reproduce this locally.

Could you please show screen-by-screen which options you are showing while creating the new VM in virt-manager?

Also please show the results of:

dpkg -l | grep libvirt
dpkg -l | grep qemu
which qemu-system-x86_64
ls -l `which qemu-system-x86_64`
sha1sum `which qemu-system-x86_64`
kvm-spice -version

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.]

Note we are waiting for information to help debug this. Please do not re-mark this confirmed without first adding the information.

pt_chown is executed when adding a serial console backed by a pts chardev:

It is the same problem as https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/632696

      <serial type='pty'>
        <target port='0'/>
      </serial>

I get the same error on the second start of the VM after a reboot of the host, not on the first one (I don't know why).

Jun 9 04:06:24 host kernel: [ 2588.975014] audit: type=1400 audit(1433847984.691:97): apparmor="DENIED" operation="open" profile="libvirt-ee2d78ea-af2f-4e82-9b0e-ef75470ff81e" name="/proc/7809/fd/" pid=7809 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=108 ouid=108
Jun 9 04:06:24 host kernel: [ 2588.975073] audit: type=1400 audit(1433847984.691:98): apparmor="DENIED" operation="exec" profile="libvirt-ee2d78ea-af2f-4e82-9b0e-ef75470ff81e" name="/usr/lib/pt_chown" pid=7809 comm="qemu-system-x86" requested_mask="x" denied_mask="x" fsuid=108 ouid=0

Adding:

  /usr/lib/pt_chown ix,
  owner @{PROC}/[0-9]*/fd/* r,

To /etc/apparmor.d/abstractions/libvirt-qemu fixes the problem for me.

Could you please test whether just adding

  /usr/lib/pt_chown ix,
  owner @{PROC}/0-9*/fd/ r,

also suffices?

(ping)

Hi Serge, sorry, I wasn't receiving email notifications (I thought it happened automatically when one ticked "this affects me").

I can't test on that system as it's in production now. I may be able to test on another system later, but probably not in July. It shouldn't be difficult to reproduce though.

What worries me more here is that it sometimes work, as in it sometimes manages to run pt_chown even though apparmor should have prohibited it. It may be an indication that there's some security weakness here.

I made configuration changes when the issue originally occurred and despite reverting the ones I can identify cannot now reproduce the issue - although I suspect that is because I've forgotten one or more changes I made.

Ok, thanks - we will add that to the 1.2.16 merge, then we can SRU.

Please note here if you need this SRU'd to vivid, or only to trusty.

Serge, I think the real question is how it can work for some people, without the

/usr/lib/pt_chown ix,

how can it work at all (for VMs with a serial port backed by a pty device, which should be the default with a typical libvirt deployment).

This bug was fixed in the package libvirt - 1.2.16-2ubuntu3

---------------
libvirt (1.2.16-2ubuntu3) wily; urgency=medium

  * debian/apparmor/libvirt-qemu:
    allow serial console backed by pts chardev (LP: #1342083)

 -- Chris J Arges <email address hidden> Tue, 07 Jul 2015 16:38:17 -0500

Hello TJ, or anyone else affected,

Accepted libvirt into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/1.2.2-0ubuntu13.1.15 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I got this on current wily:

[112561.711239] audit: type=1400 audit(1441743584.472:152): apparmor="DENIED" operation="open" profile="libvirt-e6d2c4fc-e234-4c35-f059-1bfa1fd67501" name="/proc/19534/fd/" pid=19534 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=121 ouid=121
[112561.712381] audit: type=1400 audit(1441743584.472:153): apparmor="DENIED" operation="capable" profile="libvirt-e6d2c4fc-e234-4c35-f059-1bfa1fd67501" pid=19534 comm="pt_chown" capability=3 capname="fowner"

removing the serial device is a workaround for now..

@tjaalton,

can you show the contents of /etc/apparmor.d/abstractions/libvirt-qemu ?

here you go

nevermind, my issue was caused by piuparts messing the /dev/pts mount permissions..

The fix for this bug has been awaiting testing feedback in the -proposed repository for trusty for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

I failed to reproduce the original problem, but the -proposed packages pass the qa regression tests in lp:qa-regression-tests.

Lubuntu 15.10 64bit, Lenovo t450s:

I too see this issue. I have this fix in /etc/apparmor.d/abstractions/libvirt-qemu:

    # allow serial console backed by pts chardev (LP: #1342083)
    /usr/lib/pt_chown ix,
    owner @{PROC}/0-9*/fd/ r,

but still see an apparmor issue in /var/log/kern.log. But it does seem intermittent. If I reboot this system, it'll probably work again.

kern.log:

Feb 24 10:31:39 rexs-t450s kernel: [68855.173512] audit: type=1400 audit(1456338699.233:57): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-5f4214d2-91d5-49ac-be10-dc1efa2ea391" pid=1541 comm="apparmor_parser"
Feb 24 10:31:39 rexs-t450s kernel: [68855.173717] audit: type=1400 audit(1456338699.233:58): apparmor="STATUS" operation="profile_load" profile="unconfined" name="qemu_bridge_helper" pid=1541 comm="apparmor_parser"
Feb 24 10:31:39 rexs-t450s kernel: [68855.218794] device vnet0 entered promiscuous mode
Feb 24 10:31:39 rexs-t450s kernel: [68855.234823] virbr1: port 2(vnet0) entered listening state
Feb 24 10:31:39 rexs-t450s kernel: [68855.234830] virbr1: port 2(vnet0) entered listening state
Feb 24 10:31:39 rexs-t450s kernel: [68855.444422] audit: type=1400 audit(1456338699.505:59): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-5f4214d2-91d5-49ac-be10-dc1efa2ea391" pid=1625 comm="apparmor_parser"
Feb 24 10:31:39 rexs-t450s kernel: [68855.454929] audit: type=1400 audit(1456338699.517:60): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="qemu_bridge_helper" pid=1625 comm="apparmor_parser"
Feb 24 10:31:39 rexs-t450s kernel: [68855.494790] device vnet1 entered promiscuous mode
Feb 24 10:31:39 rexs-t450s kernel: [68855.510824] virbr2: port 2(vnet1) entered listening state
Feb 24 10:31:39 rexs-t450s kernel: [68855.510837] virbr2: port 2(vnet1) entered listening state
Feb 24 10:31:39 rexs-t450s kernel: [68855.658917] audit: type=1400 audit(1456338699.721:61): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-5f4214d2-91d5-49ac-be10-dc1efa2ea391" pid=1696 comm="apparmor_parser"
Feb 24 10:31:39 rexs-t450s kernel: [68855.667013] audit: type=1400 audit(1456338699.729:62): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="qemu_bridge_helper" pid=1696 comm="apparmor_parser"
Feb 24 10:31:39 rexs-t450s kernel: [68855.732437] audit: type=1400 audit(1456338699.793:63): apparmor="DENIED" operation="open" profile="libvirt-5f4214d2-91d5-49ac-be10-dc1efa2ea391" name="/proc/1701/fd/" pid=1701 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=112 ouid=112
Feb 24 10:31:39 rexs-t450s kernel: [68855.733164] audit: type=1400 audit(1456338699.793:64): apparmor="DENIED" operation="capable" profile="libvirt-5f4214d2-91d5-49ac-be10-dc1efa2ea391" pid=1701 comm="pt_chown" capability=3 capname="fowner"
Feb 24 10:31:39 rexs-t450s kernel: [68855.738959] virbr2: port 2(vnet1) entered disabled state
Feb 24 10:31:39 rexs-t450s kernel: [68855.740443] device vnet1 left promiscuous mode
Feb 24 10:31:39 rexs-t450s kernel: [68855.740446] virbr2: port 2(vnet1) entered disabled state
Feb 24 10:31:39 rexs-t450s kernel: [68855.775011] virbr1:...

Hi,

you should be able to work around it by adding

  capability fowner,

to that file. Note that /etc/apparmor.d/abstractions/libvirt-qemu on my
system already has that. I wonder whether your file libvirt-qemu abstractions
file may be out of date? Can you paste it here?

Hi Serge,

libvirt-qemu file is attached on #23 :) Let me know what else you need.

Note: I did remove the serial console hardware component from the VM since I didn't need it, and things worked ok after that.

Thanks - that's very odd, since your file actually does include 'capability fowner', which is what the syslog says was denied. Are these qemu vms, or are they containers?

It's a VM (centos7-based system)

Oh, I misread, it's only a sub-policy that has cap-fowner.

pt_chown is not exactly trusted to begin with, so I'm not sure i want to allow all vms to run it with cap-fowner.

Not sure what the best way forward is.

Note to document this with the original issue:

with a a more recent libvirt/qemu stack (2.5/2.8) or later (maybe before but that is not important)
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
(or both together)
work fine now even without this rule.

Upstream changed so we no more need to carry this in newer releases of libvirt/qemu.

Also this way to set up the consoles is in the default template of UVT, so it is usually tested early and often in a dev cycle if it would show up again.