Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 4 Feb 2025 18:46:37 +0000
Andrea Bolognani <abologna@redhat.com> wrote:

> On Tue, Feb 04, 2025 at 05:22:42PM +0100, Stefano Brivio wrote:
> > On Tue, 4 Feb 2025 15:50:43 +0000 Andrea Bolognani <abologna@redhat.com> wrote:  
> > > 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?  
> 
> 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.

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.

> > > 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.  
> 
> 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.

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).

> > 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?

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 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.

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.

-- 
Stefano