3 ms·
I agree in general. But in this case - look at the actual source code: https://github.com/qemu/qemu/blob/master/qemu-seccomp.c https://github.com/qemu/qemu/blo
by aseipp 10y ago
I agree in general. But in this case - look at the actual source code:
https://github.com/qemu/qemu/blob/master/qemu-seccomp.c https://github.com/qemu/qemu/blob/master/qemu-seccomp.c
There's also no further refinement of seccomp privileges at runtime, so that list of syscalls is statically whitelisted up front and nothing else is done (search 'seccomp' in the repository). Is there anything I obviously couldn't achieve with that list of syscalls?
Given the list of what's whitelisted for the whole process, I wouldn't put much stock in it, for now. qemu would probably need some real upgrades and significant work to make this more fine grained and reduce the attack surface using it (both against the kernel and for rogue programs attacking the host qemu instance itself).
- wyldfire 10y agoYou're right, I hadn't checked this list. If open() were missing from the list it might be much harder to do damage outside the current VM. It's the most critical one in this whitelist IMO. Many/most of the remaining would have their scope limited to currently open fds/this-process' maps/segments.