On Wed, 22 Feb 2023 14:30:21 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Feb 22, 2023 at 02:21:29PM +0100, Stefano Brivio wrote:
qemuSecurityCommandRun() causes an explicit domain transition of the new process, but passt ships with its own SELinux policy, with external interfaces for libvirtd, so we simply need to transition from virtd_t to passt_t as passt is executed. The qemu type enforcement rules have little to do with it.
That is, if we switch to svirt_t, passt will run in the security context that's intended for QEMU, which allows a number of operations not needed by passt. On the other hand, with a switch to svirt_t, passt won't be able to create its own PID file.
Usage of those new interfaces is implemented by this change in selinux-policy: https://github.com/fedora-selinux/selinux-policy/pull/1613
Replace qemuSecurityCommandRun() with virCommandRun(), and explicitly set the label, preserving the correct MCS range for the given VM instance. This is a temporary measure: eventually, we'll need a more generic and elegant mechanism for helper binaries.
I'd really prefer to see the security manager used from the start, rather than committing code with a TODO that should be practical to implement straight away.
Feel free, by all means. As to myself, I can't realistically implement missing parts of the security manager code that I'm entirely unfamiliar with, and seriously test the whole thing before the 9.1.0 release freeze, which happens to be... today. So I see four alternatives: 1. accept this fix, 2. somebody else fixes this "properly", 3. drop the passt networking back-end, 4. ship a completely broken feature. -- Stefano