On Wed, Sep 04, 2024 at 04:58:14PM -0400, Steven Sistare wrote: > On 8/21/2024 2:34 PM, Peter Xu wrote: > > On Fri, Aug 16, 2024 at 01:09:23PM -0400, Steven Sistare wrote: > > > > > > libvirt starts qemu with the -sandbox spawn=deny option which blocks > > > fork, exec, > > > and change namespace operations. I have a patch in my workspace to be > > > submitted > > > later called "seccomp: fine-grained control of fork, exec, and namespace" > > > that allows > > > libvirt to block fork and namespace but allow exec. > > > > The question is whether that would be accepted, and it also gives me the > > feeling that even if it's accepted, it might limit the use cases that cpr > > can apply to. > > This is more acceptable for libvirt running in a container (such as under > kubevirt) > with a limited set of binaries in /bin that could be exec'd. In that case > allowing > exec is more reasonable.
Running inside a container does protect the host to a significant degree. I'd say it is still important, however, to protect the control plane (libvirt's daemons & kubevirt's agent) from the QEMU process being managed, and in that case it still looks pretty compelling to deny exec. > > What I read so far from Dan is that cpr-transfer seems to be also preferred > > from Libvirt POV: > > > > https://lore.kernel.org/r/zr9-ivorkgjre...@redhat.com > > > > Did I read it right? > > I read that as: cpr-transfer is a viable option for libvirt. I don't hear him > excluding the possibility of cpr-exec. > > I agree that "Dan the libvirt expert prefers cpr-transfer" is a good reason to > provide cpr-transfer. Which I will do. Both approaches have significant challenges for integration, but my general preference is towards a solution that doesn't require undermining our security protections. When starting a VM we have no knowledge of whether a user may want to use CPR at a later date. We're not going to disable the seccomp sandbox by default, so that means cpr-exec would not be viable in a default VM deployment. Admins could choose to modify /etc/libvirt/qemu.conf to turn off seccomp, but I'm very much not in favour of introducing a feature that requires them todo this. It would be a first in libvirt, as everything else we support is possible to use with seccomp enabled. The seccomp opt-out is essentially just there as an emergency escape hatch, not as something we want used in production. > We are at an impasse on this series. To make forward progress, I am willing > to > reorder the patches, and re-submit cpr-transfer as the first mode, so we can > review and pull that. I will submit cpr-exec as a follow on and we can resume > our arguments then. Considering the end result, are there CPR usage scenarios that are possible with cpr-exec, that can't be achieved with cpr-transfer ? Supporting two ways to doing the same thing is increasing the maint burden for QEMU maintainers, as well as downstream testing engineers who have to validate this functionality. So unless there's compelling need to support both cpr-transfer and cpr-exec, it'd be nice to standardize on just one of them. cpr-transfer does look like its probably more viable, even with its own challenges wrt resources being opened twice. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
