STC860:Tuleta-L:KVM:iap01:Ubuntu 16.10 KVM logs apparmor="DENIED"

------- Comment From <email address hidden> 2016-09-12 12:05 EDT-------
== Comment: #1 - Application Cdeadmin <email address hidden> - 2016-08-12 14:40:44 ====== State: Assigned by: cde00 on 12 September 2016 11:04:44 ====

Confirmed by SMB

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

Checking the code I'd expect that this kind of access is from:

static void qemu_thread_set_name(QemuThread *thread, const char *name)
{
#ifdef CONFIG_PTHREAD_SETNAME_NP
    pthread_setname_np(thread->thread, name);
#endif
}

This is non fatal, just fails to set the thread name (note that the return value is intentionally ignored).

The code itself if rather old (since qemu 2.0) but not enabled by default.
You could be enabled by:
  -name debug-threads=on

Since this change it is enabled by default by libvirt if supported:
https://www.redhat.com/archives/libvir-list/2016-March/msg00428.html

So with Yakkety you get e.g.
-name guest=testvm1,debug-threads=on
While on Xenial you got:
-name guest=testvm1

That feature enabled is what triggers the apparmor issues now.

Hi,
sometimes the verification of this bug seems to elude me.

So I made a test build available for you to test if the package in https://launchpad.net/~paelzer/+archive/ubuntu/libvirt-bug-1546674-1615550/+packages would help you to get rid of the reported issue.

Hi Christian,

While looking at LP: #1546674 I ran into this bug as well. Your PPA package patches the usr.sbin.libvirtd profile but I think the right place to add the rule is in the abstraction/libvirt-qemu profile extract.

I added a similar but slightly more restrictive rule in the attached patch. With that patch in, I no longer get AA denials for /proc/$pid/task/*/comm.

------- Comment From <email address hidden> 2016-10-26 16:57 EDT-------
cde00 (<email address hidden>) added native attachment /tmp/AIXOS06098138/aa-libvirt-qemu.patch on 2016-10-26 15:57:26

The attachment "aa-libvirt-qemu.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Hi Simon,
as stated in the other bug I can only agree!

Thanks - I made a new version ready to test for Yakkety available in the ppa.

------- Comment From <email address hidden> 2016-11-02 10:40 EDT-------
==== State: Assigned by: mgrosch on 02 November 2016 09:33:55 ====

#=#=# 2016-11-02 09:33:53 (CDT) #=#=#
New Fix_Potential = [GSI_HDW]

not a super high priority for 11/18 GA - we should try out the latest change though
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#

FYI - Fix pushed to Zesty

Since it is non fatal I did not consider an SRU so far.

What worked last week doesn't have to this week - I ran into an FTBFS - please wait a bit until resolved.

------- Comment From <email address hidden> 2016-11-18 10:59 EDT-------

Default Comment by Bridge

Default Comment by Bridge

Default Comment by Bridge

FYI - this is still waiting to migrate, so while the fix is committed you can not get it via an apt-get update, so it is expected to still fail atm.

This bug was fixed in the package libvirt - 2.1.0-1ubuntu13

---------------
libvirt (2.1.0-1ubuntu13) zesty; urgency=medium

  * drop d/p/ubuntu/fix-ftbfs-for-gnutls-3-5-6.patch as the offending change
    in gnutls has been reverted (LP: #1641615)
  * Build depend on gnutls >= 3.5.6-4ubuntu2 to build after the gnutls fix
    migrated

 -- Christian Ehrhardt <email address hidden> Thu, 17 Nov 2016 08:43:10 +0100

Since the issue is non-fatal and not a super-high-prio-feature to be needed I refuse to do an SRU of this into Yakkety without anybody explicitly requesting that.
Pre-Yakkety the issue was not existing (came in upstream in 2.x)
I add a task for Yakkety and flag it so that this state is clear.