Re: [libvirt] [PATCH v2 3/5] apparmor: allow expected /tmp access patterns

Several cases were found needing /tmp, for example ceph will try to list /tmp This is a compromise of security and usability: - we only allow generally enumerating the base dir - enumerating anything deeper in the dir is at least guarded by the "owner" restriction, but while that protects files of other services it won't protect qemu instances against each other as they usually run with the same user. - even with the owner restriction we only allow read for the wildcard path Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com&gt; --- examples/apparmor/libvirt-qemu | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 5caf14e418..6971d3db03 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -180,6 +180,18 @@ # for rbd /etc/ceph/ceph.conf r, + # Various functions will need to enumerate /tmp (e.g. ceph), allow the base + # dir and a few known functions like samba support. + # We want to avoid to give blanket rw permission to everything under /tmp, + # users are expected to add site specific addons for more uncommon cases. + # Qemu processes usually all run as the same users, so the "owner" restriction + # prevents access to other services files, but not across different instances. + # This is a tradeoff between usability and security - if paths would be more + # predictable that would be preferred - at least for write rules we would + # want more unique paths per rule. + /{,var/}tmp/ r, + owner /{,var/}tmp/**/ r, + # for file-posix getting limits since 9103f1ce /sys/devices/**/block/*/queue/max_segments r,