On Mon, Jun 18, 2012 at 09:31:03AM +0100, Daniel P. Berrange wrote: > 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.
Or, of course, for a QEMU already confined by SELinux. > 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. 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 :|
