On Mon, Jul 23, 2012 at 12:59 PM, Eduardo Otubo <[email protected]> wrote: > 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 :)
The patches look OK as the first step. I think the next step (1.3?) should be to adjust the code to launch a couple of threads with different sets of allowed system calls based on their needs. > >> >> 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 > [email protected] >
