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: Paul Moore
Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing
Date: Fri, 26 Apr 2013 17:07:50 -0400
User-agent: KMail/4.10.2 (Linux/3.8.5-gentoo; KDE/4.10.2; x86_64; ; )

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.

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.

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

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

-- 
paul moore
security and virtualization @ redhat




reply via email to

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