http://bugzilla.opensuse.org/show_bug.cgi?id=1058847 http://bugzilla.opensuse.org/show_bug.cgi?id=1058847#c1 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|suse-beta@cboltz.de |jfehlig@suse.com --- Comment #1 from Christian Boltz --- Your added ptrace rule matches the second log event you listed. You might need to add another ptrace rule with peer=unconfined for the first log event - but I wonder why libvirtd needs to ptrace another process, and which one it is. The libvirtd profile is shipped by libvirt-daemon, therefore reassigning to James. (I'll keep an eye on this bug nevertheless ;-) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1058847 http://bugzilla.opensuse.org/show_bug.cgi?id=1058847#c3 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |suse-beta@cboltz.de --- Comment #3 from Christian Boltz --- (In reply to James Fehlig from comment #2)

I'm not able to reproduce on TW 20170825

20170825 sounds like you still have kernel 4.12.x. AppArmor ptrace mediation was introduced in kernel 4.13 (TW 20170913), so it's not surprising you don't see it ;-) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1058847 http://bugzilla.opensuse.org/show_bug.cgi?id=1058847#c8 --- Comment #8 from Christian Boltz --- (In reply to James Fehlig from comment #7)

I've submitted a temporary fix to Factory based on latest upstream discussion: SR#527593. With the fix I'm also able to start confined domains.

I hope this is really only a *temporary* fix - the rules you added are very broad and allow much more than needed. (Feel free to forward this comment to the upstream mailinglist ;-) FYI: (u)mount, signal and pivot_root will be supported by kernel 4.14, and 4.15 will have unix and dbus rule support. Also, the plan (fate#323500) is to support them in Leap/SLE 15. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1058847 http://bugzilla.opensuse.org/show_bug.cgi?id=1058847#c11 --- Comment #11 from Christian Boltz --- (In reply to James Fehlig from comment #9)

Do profile rules covering these checks need to be conditionalized based on version? I.e., is it safe to have signal rules when not supported by the kernel? I haven't noticed any problems with such rules on my kernel 4.13 TW machine.

No problem - the only thing you need is a new enough apparmor_parser that understands signal etc. rules. AFAIK "new enough" means 2.9, so you won't hit any problems in Leap (2.10.x) or Tumbleweed (2.11). If the kernel does not know about a rule type, these rules (for example signal) will be ignored and signals will be allowed without any restrictions. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1058847 http://bugzilla.opensuse.org/show_bug.cgi?id=1058847#c13 --- Comment #13 from Christian Boltz --- Can you please send v3? ;-) + ptrace (tace) peer=(label= {profile_name}), should be + ptrace (trace) peer=@{profile_name}, That's "trace" instead of "tace", you'll need an @ to prefix variables, and ptrace rules don't accept the "peer=(label=...)" syntax ;-) That said - what's the intention of this rule? IMHO the other two should be enough. (See also Jamie's mail https://www.redhat.com/archives/libvir-list/2017-September/msg00841.html - but he also missed the @ for the variable) I also wonder about type=AVC msg=audit(1506112632.186:1324): apparmor="DENIED" operation="ptrace" profile="/usr/sbin/libvirtd" pid=8342 comm="libvirtd" requested_mask="trace" denied_mask="trace" peer="libvirt-66154842-e926-4f92-92f0-1c1bf61dd1ff" Your added rules don't cover this, so you'll probably need another rule ptrace trace peer=libvirt-*, (or a more detailed AARE if you prefer to keep it more restrictive) Also, it looks like you need to add /etc/libnl/classid r, to the virt-aa-helper profile. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1058847 http://bugzilla.opensuse.org/show_bug.cgi?id=1058847#c15 James Fehlig changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #15 from James Fehlig --- We managed to get this hashed out upstream. All changes have been committed to libvirt.git and backported for Factory/SLE15 - SR#528890. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1058847 http://bugzilla.opensuse.org/show_bug.cgi?id=1058847#c17 --- Comment #17 from Christian Neyers --- (In reply to Christian Neyers from comment #16)

Great to see, but I'm a tad confused about the current version in the Tumbleweed repositories.

The version I had issues with was 3.6.0-2.1. A zypper dup on 2017-09-25 didn't show any updates for me.

Yesterday, 3.7.0-1.1 was made available. After the update, everything works fine apparently.

Now here is my point: The apparmor patch is only included in 3.7.0-2.1. Why does it work already?

I made sure to replace my modified /etc/apparmor.d/usr.sbin.libvirtd with the one in libvirt-daemon-3.7.0-1.1.x86_64.rpm. grep'ing through /etc didn't show anything related to the new rules.

Also did an aa-enforce /etc/apparmor.d/usr.sbin.libvirtd.

Is there something I'm missing?

I'm sorry, this is invalid. Before posting, I seem to have done something (that I cannot remember) and now it's back to the expected state. -- You are receiving this mail because: You are on the CC list for the bug.