diff options
| -rw-r--r-- | contrib/apparmor/usr.bin.passt | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/contrib/apparmor/usr.bin.passt b/contrib/apparmor/usr.bin.passt index 9568189..62a4514 100644 --- a/contrib/apparmor/usr.bin.passt +++ b/contrib/apparmor/usr.bin.passt @@ -27,4 +27,25 @@ profile passt /usr/bin/passt{,.avx2} { owner @{HOME}/** w, # pcap(), pidfile_open(), # pidfile_write() + + # Workaround: libvirt's profile comes with a passt subprofile which includes, + # in turn, <abstractions/passt>, and adds libvirt-specific rules on top, to + # allow passt (when started by libvirtd) to write socket and PID files in the + # location requested by libvirtd itself, and to execute passt itself. + # + # However, when libvirt runs as unprivileged user, the mechanism based on + # virt-aa-helper, designed to build per-VM profiles as guests are started, + # doesn't work. The helper needs to create and load profiles on the fly, which + # can't be done by unprivileged users, of course. + # + # As a result, libvirtd runs unconfined if guests are started by unprivileged + # users, starting passt unconfined as well, which means that passt runs under + # its own stand-alone profile (this one), which implies in turn that execve() + # of /usr/bin/passt is not allowed, and socket and PID files can't be written. + # + # Duplicate libvirt-specific rules here as long as this is not solved in + # libvirt's profile itself. + /usr/bin/passt r, + owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw, + owner @{run}/libvirt/qemu/passt/* rw, } |