[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
Re: [Qemu-devel] [RFC] Continuous work on sandboxing, Corey Bryant, 2013/04/29