> 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
