Re: [pve-devel] Consideration of contributing Apparmor for KVM

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

> Sven Springer via pve-devel <pve-devel@lists.proxmox.com> hat am 28.04.2025 15:50 CEST geschrieben:
> Hello,
> 
> for a project we are working on a simple Apparmor profile for KVM-based 
> VMs in Proxmox.
> For now it's a POC with a static profile for the qemu-system-x86_64 
> binary. The next step would be to patch the Proxmox Perl code to 
> implement a basic version of dynamic profiles, similar to how it's done 
> for LXC by Proxmox, or how it's done by libvirt for QEMU/KVM.
> 
> Now the thought of bringing this upstream was brought up, but I am a 
> little concerned about the scope of this endeavor (in particular 
> considering limited to no perl experience on our side).
> I am also aware that there have been requests about this feature by 
> other users in the forum and on the bug report board, but no specific 
> promises have been made nor does it appear in the Roadmap 
> (https://pve.proxmox.com/wiki/Roadmap).
> 
> Implementing it for a limited scope/usecase (e.g. only x86, only testing 
> with some storage type, not testing for a plethora of pass-through 
> possibilities) seems doable enough, but is this even something you would 
> even consider accepting as a contribution, or is it more an 
> all-or-nothing situation where most if not all edgecases need to be 
> covered from the get-go?
> 
> Any feedback is much appreciated.

hi!

this is something that would be indeed very nice to have, and has been
requested a few times already:

https://bugzilla.proxmox.com/show_bug.cgi?id=5270

as you already noted, the tricky part is covering all the different
storage types and other similar "extension points". for storages,
one question to discuss is whether we want to derive a "storage profile"
that allows access to (all) volumes stored on a given storage, or
whether we'd want to derive a "volume profile" that allows access to a
given specific volume. both come with pros and cons - one profile per
storage is probably easier to implement, but doesn't cover cross-VM
exploits.

starting off with basic support for common setups and making that
opt-in is probably a sensible approach. compared to containers, some
complexity is removed (e.g., no handling of mount points ;)), but
some other complexity is gained (the QEMU process does a lot more at
runtime that needs to be properly covered by the profile).

and even just some real world experimenting would already help with
implementing this feature, e.g., a base profile for the QEMU process
itself for a given config that can be used as a starting point.

if you haven't already, check out our developer docs at

https://pve.proxmox.com/wiki/Developer_Documentation

in particular the style, preparing/sending patches and licensing sections.

maybe you could send a more in-depth RFC with some basic architecture
or design and open questions once you have that?

Fabian


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel