Re: [Qemu-devel] [PATCHv4 0/4] Sandboxing Qemu guests with Libseccomp

[Eduardo Otubo <otubo@linux.vnet.ibm.com>]

On Tue, Jul 17, 2012 at 04:19:11PM -0300, Eduardo Otubo wrote:
> Hello all,
> 
> This patch is an effort to sandbox 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.
> 
> It's important to note that the libseccomp itself needs the seccomp mode 2
> feature in the kernel, which is only available in kernel versions older (or
> equal) than 3.5-rc1.
> 
> v2: Files separated in qemu-seccomp.c and qemu-seccomp.h for a cleaner
>     implementation. The development was tested with the 3.5-rc1 kernel.
> 
> v3: As we discussed in previous emails in this mailing list, this feature is
>     not supposed to replace existing security feature, but add another layer to
>     the whole. The whitelist should contain all the syscalls QEMU needs. And as
>     stated by Will Drewry's commit message[1]: "Filter programs will be inherited
>     across fork/clone and execve.", the same white list should be passed along from
>     the father process to the child, then execve() shouldn't be a problem. Note
>     that there's a feature PR_SET_NO_NEW_PRIVS in seccomp mode 2 in the kernel,
>     this prevents processes from gaining privileges on execve. For example, this
>     will prevent qemu (if running unprivileged) from executing setuid programs[2].
> 
> v4: Introducing "debug" mode on libseccomp support. The "debug" mode will set
>     the flag SCMP_ACT_TRAP when calling seccomp_start(). It will verbosely
>     print a message to the stderr in the form "seccomp: illegal system call
>     execution trapped: XXX" and resume the execution. This is really just used as
>     debug mode, it helps users and developers to full fill the whitelist.
> 
> As always, comments are more than welcome.

Hello folks,

Does anyone got a chance to take a look at these? Thanks in advance :)

> 
> Regards,
> 
> [0] - http://sourceforge.net/projects/libseccomp/
> [1] - http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=e2cfabdfd075648216f99c2c03821cf3f47c1727
> [2] - https://lkml.org/lkml/2012/4/12/457
> 
> Eduardo Otubo (4):
>   Adding support for libseccomp in configure and Makefile
>   Adding qemu-seccomp.[ch]
>   Adding qemu-seccomp-debug.[ch]
>   Adding seccomp calls to vl.c
> 
>  Makefile.objs        |   10 ++++
>  configure            |   34 ++++++++++++++
>  qemu-seccomp-debug.c |   95 +++++++++++++++++++++++++++++++++++++
>  qemu-seccomp-debug.h |   38 +++++++++++++++
>  qemu-seccomp.c       |  126 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  qemu-seccomp.h       |   22 +++++++++
>  vl.c                 |   31 +++++++++++++
>  7 files changed, 356 insertions(+)
>  create mode 100644 qemu-seccomp-debug.c
>  create mode 100644 qemu-seccomp-debug.h
>  create mode 100644 qemu-seccomp.c
>  create mode 100644 qemu-seccomp.h
> 
> -- 
> 1.7.9.5
> 

-- 
Eduardo Otubo
Software Engineer
Linux Technology Center
IBM Systems & Technology Group
Mobile: +55 19 8135 0885 
eotubo@linux.vnet.ibm.com