Re: [Qemu-devel] [PATCH v6 0/3] Sandboxing Qemu guests with Libseccomp

[Anthony Liguori]

Overall the code looks fine to me.

A couple general comments though:

- we need a -disable-sandbox flag in case the whitelist is bad and a
  user needs to disable it.

- for the few cases where we may exec something that requires privileges
  beyond this white list, we need to clearly document that
  -disable-sandbox may be needed.

Most scripts should be fairly limited in what they try to do so I think
that the existing sandbox should be okay.  Confirming that the existing
sandbox is enough to do ifconfig $tap 0.0.0.0 up && brctl addbr br0 $tap
would be nice too.

I'm a little concerned this hasn't gotten enough testing to enable by
default in 1.2.  So I'd suggest adding:

-sandbox on

Parse this argument via QemuOpts and make the default parameter
'enable'.  This will let us extend the white list in the future.  For
the 1.2 release, make the default for sandbox.enable=off but for 1.3,
will switch it to 'on' for the default.

By making it QemuOpts, we can actually disable/enable through the global
configuration file which is a really nice touch.

If you can make those changes and resubmit tomorrow, we can include it
for the 1.2 release.

Regards,

Anthony Liguori

Eduardo Otubo <address@hidden> writes:

> 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.
>
> v5: Libseccomp release 1.0.0[3]: The API now is context aware and it breaks 
> the
>     compatibility with older versions. I updated all the functions that 
> differs
>     from one version to another.
>
> v6: Debug mode removed as discussed in the list/irc. Planned for future 
> inclusion.
>
> As always, comments are more than welcome.
>
> 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
> [3] - 
> http://sourceforge.net/mailarchive/forum.php?thread_name=1633205.5jr3eG7nQ5%40sifl&forum_name=libseccomp-discuss
>
>
> Eduardo Otubo (3):
>   Adding support for libseccomp in configure and Makefile
>   Adding qemu-seccomp.[ch]
>   Adding seccomp calls to vl.c
>
>  Makefile.objs  |    6 ++
>  configure      |   22 +++++++++
>  qemu-seccomp.c |  139 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  qemu-seccomp.h |   22 +++++++++
>  vl.c           |   13 +++++
>  5 files changed, 202 insertions(+), 0 deletions(-)
>  create mode 100644 qemu-seccomp.c
>  create mode 100644 qemu-seccomp.h