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

[Eduardo Otubo <otubo@linux.vnet.ibm.com>]

On 04/29/2013 07:02 PM, Corey Bryant wrote:
>
>
> 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.

I think we're talking about the same thing here. I believe the execution 
flow will happen like this: 1) first whitelist installed, only few 
syscalls allowed. 2) qemu starts 3) given the current scenario (the 
current list of syscalls allowed) the second *blacklist* is installed, 
denying execve and open. 4) start guests.

At the end of step 3, we'll have the same environment we have at step 1, 
without execve and open. Is that correct?

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

-- 
Eduardo Otubo
IBM Linux Technology Center