On Tue, Jun 19, 2012 at 9:23 AM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Mon, Jun 18, 2012 at 08:15:37PM +0000, Blue Swirl wrote: >> 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. > > That's just another example of my point, that adding seccomp alone > does nothing for QEMU security. It is only valuable when combined > with another security technique, be it per-user DAC separation, > SELinux MAC, or chroot, or splitting QEMU into multiple separate > processes, or using Linux containers to confine it, etc
I think seccomp with some changes to either functionality or with minor refactoring could do a lot more than with just 'accept all' white list. But as a starting point, this is sort of OK. > > > 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 :|