[Pkg-libvirt-maintainers] Bug#878153: Bug#878153: libvirt-daemon-system: frequent AppArmor denials for ptrace of some unconfined process

[Guido Günther]

Hi,
On Tue, Oct 10, 2017 at 02:54:50PM +0100, Simon McVittie wrote:
> Package: libvirt-daemon-system
> Version: 3.7.0-4
> Severity: normal
> 
> In recent uses of libvirtd (I would guess the last couple of weeks) I get
> frequent AppArmor denials from libvirtd attempting to trace some
> unconfined process:
> 
> Oct 10 14:35:58 perpetual kernel: audit: type=1400 audit(1507642558.099:2336): apparmor="DENIED" operation="ptrace" profile="/usr/sbin/libvirtd" pid=14324 comm="libvirtd" requested_mask="trace" denied_mask="trace" peer="unconfined"
> Oct 10 14:35:58 perpetual kernel: audit: type=1400
> audit(1507642558.099:2337): apparmor="DENIED" operation="ptrace"
> profile="/usr/sbin/libvirtd" pid=14324 comm="libvirtd"
> requested_mask="trace" denied_mask="trace" peer="unconfined"

This happens since you're running 4.13 (which is not in testing yet AFAIK).

> 
> Unfortunately, AppArmor logs the system call that caused the denial for
> some operations, but apparently not for this one; so we can't know
> anything about the target process.
> 
> Some clues: I only get these when a VM is running. With one session://
> VM and no system:// VMs running, I get these denials in consecutive pairs,
> one pair every 3 seconds.
> 
> I believe this indicates either an actual ptrace operation, or mutating
> process state by writing into /proc (which is also audited as "ptrace"
> under at least some kernel versions). requested_mask="trace" indicates
> that libvirtd is trying to write or change the state of some other,
> unconfined process, as opposed to reading state which would be
> requested_mask="read", or being traced by an unconfined process which
> would be requested_mask="tracedby" or requested_mask="readby".
> 
> A workaround is to add this to the AppArmor profile (although this does
> let libvirtd trace unconfined processes like for example dbus-daemon and
> network-manager, which would be bad if there is meant to be a security
> boundary between them):
> 
>     ptrace peer=unconfined,
> 
> This might be https://www.redhat.com/archives/libvir-list/2017-September/msg00546.html
> in which case it's fixed in 3.8.0. If so, I'll close this when I've
> upgraded.


Yes, this should be fixed in 3.8.0, see #877926. The version in sid
doesn't fix all issues related to that but I want it to migrate first
before fixing the remaining apparmor glitch related to dnsmasq.

Cheers,
 -- Guido