qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Continuous work on sandboxing


From: Corey Bryant
Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing
Date: Mon, 29 Apr 2013 18:02:52 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5



On 04/29/2013 02:39 PM, Eduardo Otubo wrote:


On 04/26/2013 06:07 PM, Paul Moore wrote:
On Friday, April 26, 2013 03:39:33 PM Eduardo Otubo wrote:
Hello folks,

Resuming the sandboxing work, I'd  like to ask for comments on the
ideias I have:

1. Reduce whitelist to the optimal subset: Run various tests on Qemu
with different configurations to reduce to the smallest syscall set
possible; test and send a patch weekly (this is already being performed
and a patch is on the way)

Is this hooked into a testing framework?  While it is always nice to have
someone verify the correctness, having a simple tool/testsuite what
can run
through things on a regular basis is even better.

Unfortunately it is currently not. I'm running the tests manually, but I
have in mind some ideas to implement a tool for this purpose.


How about testing in KVM autotest? I assume it would be as simple as modifying some existing tests to use -sandbox on. We definitely should get some automated regression tests running with seccomp on.


Also, looking a bit further ahead, it might be interesting to look at
removing
some of the arch dependent stuff in qemu-seccomp.c.  The latest
version of
libseccomp should remove the need for many, if not all, of the arch
specific
#ifdefs and the next version of libseccomp will add support for x32
and ARM.

Tell me more about this. You're saying I can remove the #ifdefs and keep
the lines like "{ SCMP_SYS(getresuid32), 241 }, " or address these
syscalls in another way?


2. Introduce a second whitelist - the whitelist should be defined in
libvirt and passed on to qemu or just pre defined in Qemu? Also remove
execve() and avoid open() and socket() and its parameters ...

If I'm understanding you correctly, I think what you'll want is a second
*blacklist*.  We talked about this previously; we currently have a single
whitelist, and considering how seccomp works, you can really only further
restrict things after you install a whitelist into the kernel (hence the
blacklist).

Yes, that's exactly what I'm planning to do.


Hmm, I thought you were going to introduce a completely new whitelist so that a guest could optionally be run under:
1) the existing sandbox environment where everything in QEMU works,
*or*
2) a new tighter and more restricted sandbox environment where things like execve() is denied, open() is denied (once the pre-req's are in place for fd passing), and potentially other "dangerous" syscalls are denied.

If the whitelist for #2 was passed from libvirt to qemu then libvirt could define the syscalls and syscall parameters that are denied.

--
Regards,
Corey Bryant




reply via email to

[Prev in Thread] Current Thread [Next in Thread]