RFC qemu VM entrypoints
Get series with b4
b4 am C2C93606.370D%[email protected]Versions newest first
- v1 RFC Latest0 of 1 patch 0 repliesNew
Patches in v1 No applies recorded yet
The patch the cover letter announces is not in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Qemu-devel] [kvm-devel] [RFC][PATCH 00/01]qemu VM entrypoints
Quoted 37 lines
Quoted 26 lines · Joshua Brindle
Quoted 10 lines · James Morris
Quoted 3 lines · Anthony Liguori
Can you already write an selinux policy that changes the label of a process when it open()s a different file?
No, and you normally want to do this over an exec anyway, to ensure the new execution state is clean.
This is correct and the object model being proposed isn't just about opening files.
Anthony - There are several userspace object managers for SELinux, basically they manage resources that are too abstract for the kernel to manage. These include DBUS connections, X windows/pixmaps/cursors/etc, postgresql tables and rows, etc. SELinux is designed to designed to have non-centralized enforcement of the policy (but centralized decision making). In this case the object model isn't just about opening a file, its about lauching and restricting a vm based on an abstract resource, in this case a virtual disk file, that the kernel can't differenciate from any other file.
Quoted 9 lines
The reason for this abstraction is simple, think about all the files that qemu has to open that aren't disk files. For example, if you have 3 vm's, unclass, secret, top secret, those qemu processes still have to share resources, library files, configuration files, devices, potentially log, pid etc. If someone could manage to get a top secret disk labeled
lib_tthey could boot any of those vm's with that disk image (using snapshot or some feature to prevent write attempts on it), and disclose top secret data where it shouldn't be disclosed.
Quoted 8 lines
The only way that the VM could possible see the top secret data is if the disk file was readable by the QEMU process running the secret guest. That's the security problem. You address this "attack" by simply not letting the user that launched the QEMU process have read
access to the top secret disk file. Why would you ever want to allow
the QEMU process that's running a "secret" domain to have any read access to top secret files?
There will be some cases where VMs of different integrity levels have file:read permissions in common for certain files, for example, shared libraries, or other resources which may be explicitly shared.
The vm:entrypoint is similar in nature to the file:entrypoint permission. For files, only a certain trusted codebase is authorized in policy as an entrypoint into a certain domain; this codebase is given file:entrypoint permission wrt the target domain. Similarly, for virtual machines, it would be nice to authorize in policy a certain disk image as an entrypoint into a certain domain. It would also be nice to have SELinux policy decide which domain a VM will execute in not only based on the type of the virtual disk, but on the type of the process loading the virtual disk. This can be accomplished using the vm:entrypoint permission and type_transition rules. If the patch that I posted is moved to libvirt, no modification of qemu is necessary, and those wishing to use qemu (and likely other userspace backends later) would just link against libvirt and libselinux.
Thanks,
David Windsor
Quoted 11 lines
Regards,
Anthony Liguori
Quoted 6 lines
With David's object model this kind of attack can be prevented because virtual disk files aren't 'just files' to qemu, they are an abstract resource that means more than just a regular file, just like a database file is more than just a regular file for SE-Postgresql.