On Tue, 4 Feb 2025 18:46:37 +0000 Andrea Bolognani <abologna(a)redhat.com> wrote:On Tue, Feb 04, 2025 at 05:22:42PM +0100, Stefano Brivio wrote:Ah, thanks, it never occurred to me to look into that. So, yes, essentially the same thing as it's done with MCS and SELinux.On Tue, 4 Feb 2025 15:50:43 +0000 Andrea Bolognani <abologna(a)redhat.com> wrote:I'm not well-versed enough in SELinux to be able to answer the latter question, but I can answer the former. The per-VM profile is needed to ensure that each VM is only granted access to its own resources. $ sudo tail -4 /etc/apparmor.d/libvirt/libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 profile libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 flags=(attach_disconnected) { #include <abstractions/libvirt-qemu> #include if exists <libvirt/libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4.files> } $ sudo cat /etc/apparmor.d/libvirt/libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4.files "/var/log/libvirt/**/alpine.log" w, "/var/lib/libvirt/qemu/domain-alpine/monitor.sock" rw, "/var/lib/libvirt/qemu/domain-1-alpine/*" rw, "/run/libvirt/**/alpine.pid" rwk, "/run/libvirt/**/*.tunnelmigrate.dest.alpine" rw, "/var/lib/libvirt/images/alpine.qcow2" rwk, "/var/lib/libvirt/qemu/domain-1-alpine/{,**}" rwk, "/run/libvirt/qemu/channel/1-alpine/{,**}" rwk, "/var/lib/libvirt/qemu/domain-1-alpine/master-key.aes" rwk, "/dev/userfaultfd" rwk, The stuff in the libvirt-qemu abstraction is generic, all VMs get access to it. The stuff in .files is all specific to the VM.The additional profiles (libvirt-1cdfdfd3-a020-45d9-8f88-8e0ce31745c4 and its passt subprofile) are generated dynamically when the VM is started and the QEMU process gets the correct one assigned to it. So far so good.Why do we need additional profiles, I wonder? Are we trying to replicate the MCS (Multi-Category Security) stuff from SELinux?Right. That's what we did for libguestfs as well, the image can be *almost* anywhere. But it's not free-for-all: you're just granting *limited* filesystem access (not to sysfs, not to /etc, and so on). And I had to build a *very* loose profile for libguestfs because that applies to root as well, but for rootless libvirtd, it might even make sense to restrict access to just @{HOME}/** and /tmp/** (that's what I did for stand-alone passt, for example).Sounds to me like this would require granting the QEMU process access to roughly the entire filesystem? The disk image could live anywhere after all, and if we can't dynamically add a rule for the exact path the only way out is a free-for-all approach.Do you have any ideas?Probably you should ask somebody more familiar (openSUSE/Ubuntu maintainers of libvirt, or the authors of the virt-aa-helper thing?), but a couple of quick ideas: 1. user-specific subprofiles could be added at adduser time (is there a hook?) and libvirtd could use aa_change_hat(2) to select the appropriate one based on UID 2. (most reasonable I think) don't use per-VM profiles for the rootless case. Define a single "libvirt-user" (or "libvirt-session") profile and use that. We could copy it from the existing ones I suppose.Well, you are still restricting them significantly, for example they can't run random binaries, send arbitrary signals to other processes or to each other, and access a ton of places on the filesystem. Perhaps that's even more important than curbing filesystem access, because that should already be significantly restricted.I think that MCS-equivalent functionality is anyway much less critical if guests are started as unprivileged users because you have a strong separation given by the fact that guests are started as different users. If all the guests are started as root, and multiple users have access to that facility, user separation is much more seriously endangered, hence a stronger need for per-VM profiles.Ideally you'd still want to isolate unprivileged VMs from each other. If you don't, what's the point of using AppArmor in the first place?I'll try to submit a pull request at least for Debian in a couple of days. I guess it would be nice if you could ask other maintainers meanwhile. -- StefanoI can try to work on this but I'm really a bit too busy right now. If you can, great, otherwise, let me know. On the other hand this feels pretty urgent. :(I'm afraid I have neither the time nor the expertise to work on this myself.