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