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

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

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.

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

>
>> 3. Debugging and/or learning mode - third party libraries still have the
>> problem of interfering in the Qemu's signal mask. According to some
>> previous discussions, perhaps patch all external libraries that mass up
>> with this mask (spice, for example) is a way to solve it. But not sure
>> if it worth the time spent. Would like to hear you guys.
>
> I think patching all the libraries is a losing battle, I think we need to
> pursue alternate debugging techniques.
>

I agree with you. I was just thinking about working with third party 
libraries due to this thread: 
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00620.html

-- 
Eduardo Otubo
IBM Linux Technology Center