[Bug 1065123] New: libvirtd AppArmor profile: more additions for Kernel 4.14
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123 Bug ID: 1065123 Summary: libvirtd AppArmor profile: more additions for Kernel 4.14 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE 42.2 Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: jfehlig@suse.com Reporter: suse-beta@cboltz.de QA Contact: qa-bugs@suse.de Found By: Beta-Customer Blocker: --- Hi Jim, testing with Kernel 4.14 rc4 brought up that some more rules need to be added to the usr.sbin.libvirtd AppArmor profile. Note that this partially overlaps with the patch intrigeri (AppArmor maintainer in Debian) sent: https://www.redhat.com/archives/libvir-list/2017-October/msg01153.html I needed to add the following network and signal rules: network netlink raw, signal send set=hup peer=/usr/sbin/dnsmasq, signal send set=(term,kill) peer=unconfined, Also, several mount rules are needed - either as a generous "mount," rule (as proposed by intrigeri as a quick fix to allow mounting everything), or with the following detailed rules (which are more restrictive, but might still need some adjustments) mount options=(rw,rslave) -> /, mount options=(rw, nosuid) -> /{var/,}run/libvirt/qemu/*.dev/, mount options=(rw, move) /dev/ -> /{var/,}run/libvirt/qemu/*.dev/, mount options=(rw, move) /dev/hugepages/ -> /{var/,}run/libvirt/qemu/*.hugepages/, mount options=(rw, move) /dev/mqueue/ -> /{var/,}run/libvirt/qemu/*.mqueue/, mount options=(rw, move) /dev/pts/ -> /{var/,}run/libvirt/qemu/*.pts/, mount options=(rw, move) /dev/shm/ -> /{var/,}run/libvirt/qemu/*.shm/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.dev/ -> /dev/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.hugepages/ -> /dev/hugepages/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.mqueue/ -> /dev/mqueue/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.pts/ -> /dev/pts/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.shm/ -> /dev/shm/, BTW: according to my audit.log *), libvirtd still uses /var/run/ for these mounts. It might be a good idea to change the code to use /run/, but that's a completely different issue ;-) *) For historic reasons my /var/run/ is a bind-mount to /run/ so that I can see the difference in the audit.log. If your /var/run/ is a symlink to /run/, you'll only see /run/ in the audit.log because AppArmor resolves symlinks first. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123#c1
James Fehlig
testing with Kernel 4.14 rc4 brought up that some more rules need to be added to the usr.sbin.libvirtd AppArmor profile.
Some of these are needed for SLE15 (kernel 4.12.14) as well.
network netlink raw,
signal send set=hup peer=/usr/sbin/dnsmasq, signal send set=(term,kill) peer=unconfined,
These are the ones needed in SLE15. Note that Jamie suggested changing the signal rules to signal (send) peer=/usr/sbin/dnsmasq, signal (send) peer=libvirt-*,
Also, several mount rules are needed - either as a generous "mount," rule (as proposed by intrigeri as a quick fix to allow mounting everything), or with the following detailed rules (which are more restrictive, but might still need some adjustments)
mount options=(rw,rslave) -> /, mount options=(rw, nosuid) -> /{var/,}run/libvirt/qemu/*.dev/,
mount options=(rw, move) /dev/ -> /{var/,}run/libvirt/qemu/*.dev/, mount options=(rw, move) /dev/hugepages/ -> /{var/,}run/libvirt/qemu/*.hugepages/, mount options=(rw, move) /dev/mqueue/ -> /{var/,}run/libvirt/qemu/*.mqueue/, mount options=(rw, move) /dev/pts/ -> /{var/,}run/libvirt/qemu/*.pts/, mount options=(rw, move) /dev/shm/ -> /{var/,}run/libvirt/qemu/*.shm/,
mount options=(rw, move) /{var/,}run/libvirt/qemu/*.dev/ -> /dev/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.hugepages/ -> /dev/hugepages/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.mqueue/ -> /dev/mqueue/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.pts/ -> /dev/pts/, mount options=(rw, move) /{var/,}run/libvirt/qemu/*.shm/ -> /dev/shm/,
intrigeri included these rules in V3 of his series https://www.redhat.com/archives/libvir-list/2017-November/msg00162.html I think patch1 is fine and has essentially already been ACKed by Jamie. I'd prefer Jamie's feedback on patch2 as well, since I'm far from an apparmor expert. Even though they are not yet committed upstream, I'll add these patches to the Factory libvirt package so libvirt will actually work with latest TW and SLE15. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123#c2
--- Comment #2 from Christian Boltz
(In reply to Christian Boltz from comment #0)
signal send set=hup peer=/usr/sbin/dnsmasq, signal send set=(term,kill) peer=unconfined,
These are the ones needed in SLE15. Note that Jamie suggested changing the signal rules to
signal (send) peer=/usr/sbin/dnsmasq, signal (send) peer=libvirt-*,
Removing the set=... means to allow all signals, so this is fine. The rule with peer=libvirt-* also makes sense. The interesting question is if peer=unconfined (sending a signal to a program running without AppArmor confinement) is needed - IIRC I've seen such an event in my audit.log, but I'm not sure what it was. I'll re-test when the updated profile enters Tumbleweed.
Also, several mount rules are needed - either as a generous "mount," rule (as proposed by intrigeri as a quick fix to allow mounting everything), or with the following detailed rules (which are more restrictive, but might still need some adjustments) ... intrigeri included these rules in V3 of his series
https://www.redhat.com/archives/libvir-list/2017-November/msg00162.html
Yeah, he already joked that this is a real cross-distribution patchset: <intrigeri> it's nice to have a PR (libvirt upstream) prepared by a Debian person, that integrates work coming from openSUSE, and reviewed by an Ubuntu person :) <intrigeri> + chances are it's merged by a Red Hat person :)
I think patch1 is fine and has essentially already been ACKed by Jamie. I'd prefer Jamie's feedback on patch2 as well, since I'm far from an apparmor expert.
The quick summary is that the detailed mount rules are more restrictive than the general "mount," rule (which allows all mounting).
Even though they are not yet committed upstream, I'll add these patches to the Factory libvirt package so libvirt will actually work with latest TW and SLE15.
Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123#c3
James Fehlig
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123#c6
--- Comment #6 from Christian Boltz
Hmm, already mentioned in #0, but I missed sending/receiving signals from unconfined processes. The out-of-the-box default is to run QEMU/KVM instances unconfined (security_default_confined = 0 in /etc/libvirt/qemu.conf), hence no signals can be sent to reap the processes when doing e.g. 'virsh destroy dom'.
Ah, that explains peer=unconfined - intrigeri already wondered why it's needed, so please add this detail when upstreaming this rule.
I'll add a downstream patch to allow signals, but I'm not sure how restrictive the rule should be. Christian, perhaps I'll start with your suggestion but include 'hup'. E.g.
signal send set=(term,kill,hup) peer=unconfined,
I only noticed term and kill in my tests, but in comparison, hup is harmless ;-)
I think the following is a bit too loose
signal (read, send) peer=unconfined,
Right, that would allow way too much. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123#c7
--- Comment #7 from James Fehlig
Ah, that explains peer=unconfined - intrigeri already wondered why it's needed, so please add this detail when upstreaming this rule.
I don't think I'll be upstreaming the rule since security_default_confined defaults to 1 upstream. The upstream rules are sufficient for the default upstream configuration. Recall all the libvirt apparmor profiles are located under the 'examples' directory. Downstreams are free to tweak those as they desire. WRT SUSE's default of 'security_default_confined = 0', I made confinement of VMs opt-in from the beginning. To date, no one has complained about that, or filed a fate request to change it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123#c8
Christian Boltz
I've submitted a libvirt package containing the patches to Factory - SR#540061.
Christian: setting needinfo to you for your test results once this hits TW.
I can confirm that the latest profile works :-) (In reply to James Fehlig from comment #7)
WRT SUSE's default of 'security_default_confined = 0', I made confinement of VMs opt-in from the beginning. To date, no one has complained about that, or filed a fate request to change it.
See bug 1070917 ;-) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123
http://bugzilla.opensuse.org/show_bug.cgi?id=1065123#c9
James Fehlig
participants (1)
-
bugzilla_noreply＠novell.com