On Tue, 8 May 2012, Daniel P. Berrange wrote: > On Fri, May 04, 2012 at 04:08:36PM -0300, Eduardo Otubo wrote: > > Hello all, > > > > This is the first effort to sandboxing Qemu guests using Libseccomp[0]. The > > patches that follows are pretty simple and straightforward. I added the > > correct > > options and checks to the configure script and the basic calls to > > libseccomp in > > the main loop at vl.c. Details of each one are in the emails of the patch > > set. > > > > This support limits the system call footprint of the entire QEMU process to > > a > > limited set of syscalls, those that we know QEMU uses. The idea is to limit > > the allowable syscalls, therefore limiting the impact that an attacked guest > > could have on the host system. > > What functionality has been lost by applying this seccomp filter ? I've not > looked closely at the code, but it appears as if this blocks pretty much > any kind of runtime device changes. ie no hotplug of any kind will work ?
Right, I was wondering the same thing: open is not on the list so adding a new disk shouldn't be possible. Regarding Xen, most of the hypercalls go through xc_* calls that are ioctls on the privcmd device. Is it possible to add ioctl to the list?
