On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote: > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote: > > I think allowing execve() would render seccomp pretty much useless. > > Not necessarily. > > I'll agree that it does seem a bit odd to allow execve(), but there is still > value in enabling seccomp to disable potentially buggy/exploitable syscalls. > Let's not forget that we have over 300 syscalls on x86_64, not including the > 32 bit versions, and even if we add all of the new syscalls suggested in this > thread we are still talking about a small subset of syscalls. As far as > security goes, the old adage of "less is more" applies.
I can sort of see this argument, but *only* if the QEMU process is being run under a dedicated, fully unprivileged (from a DAC pov) user, completely separate from anything else on the system. If QEMU were being run as root, then even with seccomp, it could trivially just overwrite some binary in /bin, update /proc/core-pattern to point to this binary, and then crash itself. Now that core handling binary will execute without any of the seccomp filters applied. Similarly if QEMU is being run in the user's desktop session, I'm sure there is some kind of similar attack possible by changing a config setting for the user's GNOME/KDE session, and then waiting for GNOME/KDE to execute the script that QEMU just wrote out, once again bypassing seccomp. 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 :|