"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.
