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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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