On Mon, Jun 18, 2012 at 8:31 AM, Daniel P. Berrange <berra...@redhat.com> 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. > > 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
Not wiithout 'open'. When run as root, it would be nice to chroot() also to some empty directory and then drop chroot() privileges. > 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 :|