Re: [Qemu-devel] [RFC] Continuous work on sandboxing

[Paul Moore <pmoore@redhat.com>]

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