On Tuesday, April 30, 2013 04:28:54 PM Corey Bryant wrote: > Just to be clear, I'm thinking you could launch guests in one of two > different seccomp sandboxed environments: > > 1) Using the existing and more permissive whitelist where every QEMU > feature works: > > qemu-kvm -sandbox on,default
In general, I like the comma delimited list of sandbox filters/methods/etc. but I'm not sure we need to explicitly specify "default", it seems like "on" would be sufficient. It also preserved compatibility with what we have now. > 2) A more restricted whitelist environment that doesn't allow all QEMU > features to work. It would be limited to the whitelist in 1 and it > would also deny things like execve(), open(), socket(), certain ioctl() > parameters, and may only allow reads/writes to specifc fds, and/or block > anything else that could be dangerous: > > qemu-kvm -sandbox on,restricted > > I'm just throwing these command line options and syscalls out there. > And maybe it makes more sense for libvirt to pass the syscalls and > parameters to QEMU so that libvirt can determine the parameters to > restrict, like fd's the guest is allowed to read/write. > > Here's another thread where this was discussed: > http://www.redhat.com/archives/libvir-list/2013-April/msg01501.html Seems reasonable to me. -- paul moore security and virtualization @ redhat
