From: Eduardo Otubo <otubo@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: pmoore@redhat.com, aliguori@us.ibm.com, wad@chromium.org,
coreyb@linux.vnet.ibm.com, blauwirbel@gmail.com,
Eduardo Otubo <otubo@linux.vnet.ibm.com>
Subject: [Qemu-devel] [PATCH v7 0/4] Sandboxing Qemu guests with Libseccomp
Date: Tue, 14 Aug 2012 18:44:04 -0300 [thread overview]
Message-ID: <1344980648-18723-1-git-send-email-otubo@linux.vnet.ibm.com> (raw)
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.
v7: Adding command line support. If "-sandbox" is given then seccomp filter is
enabled, otherwise the default is off.
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 (4):
Adding support for libseccomp in configure and Makefile
Adding qemu-seccomp.[ch]
Adding seccomp calls to vl.c
Command line support for seccomp with -sandbox
Makefile.objs | 6 ++
configure | 22 +++++++++
qemu-config.c | 13 +++++
qemu-config.h | 1 +
qemu-options.hx | 10 ++++
qemu-seccomp.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
qemu-seccomp.h | 22 +++++++++
vl.c | 14 ++++++
8 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 qemu-seccomp.c
create mode 100644 qemu-seccomp.h
next reply other threads:[~2012-08-14 21:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 21:44 Eduardo Otubo [this message]
2012-08-14 21:44 ` [Qemu-devel] [PATCH v7 1/4] Adding support for libseccomp in configure and Makefile Eduardo Otubo
2012-08-14 21:44 ` [Qemu-devel] [PATCH v7 2/4] Adding qemu-seccomp.[ch] Eduardo Otubo
2012-08-14 21:44 ` [Qemu-devel] [PATCH v7 3/4] Adding seccomp calls to vl.c Eduardo Otubo
2012-08-14 21:44 ` [Qemu-devel] [PATCH v7 4/4] Command line support for seccomp with -sandbox Eduardo Otubo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1344980648-18723-1-git-send-email-otubo@linux.vnet.ibm.com \
--to=otubo@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=coreyb@linux.vnet.ibm.com \
--cc=pmoore@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).