On Mon, Oct 05, 2015 at 07:20:58AM +0200, Markus Armbruster wrote: > "Namsun Ch'o" <namn...@safe-mail.net> writes: > > >> If we intend seccomp to protect against flaws during QEMU setup, then > >> having > >> it earlier is neccessary. eg QEMU opening a corrupt qcow2 image which might > >> exploit QEMU before the guest CPUs start. > > > >> If the latter is the case, then we could start with a relaxed seccomp > >> sandbox which included the setuid/chroot features, and then switch to a > >> more restricted one which blocked them before main_loop() runs. > > > > That's not possible. Seccomp will not be enforced until seccomp_load(ctx) is > > called, after which no new changes to the filter can be made. > > That's a pity. > > As long as it's the case, we need to pick: either we protect against > rogue guests, or against rogue images. The original idea was the > former, and it still makes the most sense to me.
Yep, protecting against rogue guests seems much more important. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
