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

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

On 04/30/2013 02:47 PM, Eduardo Otubo wrote:
>
>
> 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

I think so, but I'm not entirely sure.

> 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.

Yes, you could implement the new whitelist this way.

>
> 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.
>>
>

Just to be clear, I'm thinking you could launch guests in one of two 
different seccomp sandboxed environments:

1) Using the existing and more permissive whitelist where every QEMU 
feature works:

qemu-kvm -sandbox on,default

2) A more restricted whitelist environment that doesn't allow all QEMU 
features to work.  It would be limited to the whitelist in 1 and it 
would also deny things like execve(), open(), socket(), certain ioctl() 
parameters, and may only allow reads/writes to specifc fds, and/or block 
anything else that could be dangerous:

qemu-kvm -sandbox on,restricted

I'm just throwing these command line options and syscalls out there. 
And maybe it makes more sense for libvirt to pass the syscalls and 
parameters to QEMU so that libvirt can determine the parameters to 
restrict, like fd's the guest is allowed to read/write.

Here's another thread where this was discussed:
http://www.redhat.com/archives/libvir-list/2013-April/msg01501.html

-- 
Regards,
Corey Bryant