Re: [Qemu-devel] [PATCHv2 3/4] Support for "double whitelist" filters

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

On 11/02/2012 05:29 PM, Paul Moore wrote:
> On Tuesday, October 23, 2012 03:55:31 AM Eduardo Otubo wrote:
>> This patch includes a second whitelist right before the main loop. It's
>> a smaller and more restricted whitelist, excluding execve() among many
>> others.
>>
>> v2: * ctx changed to main_loop_ctx
>>      * seccomp_on now inside ifdef
>>      * open syscall added to the main_loop whitelist
>>
>> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
>
> Unfortunately qemu.org seems to be down for me today so I can't grab the
> latest repo to review/verify this patch (some of my comments/assumptions below
> may be off) but I'm a little confused, hopefully you guys can help me out,
> read below ...
>
> The first call to seccomp_install_filter() will setup a whitelist for the
> syscalls that have been explicitly specified, all others will hit the default
> action TRAP/KILL.  The second call to seccomp_install_filter() will add a
> second whitelist for another set of explicitly specified syscalls, all others
> will hit the default action TRAP/KILL.

That's correct.  The goal was to have a 2nd list that is a subset of the 
1st list, and also not include execve() in the 2nd list.  At this point 
though, since it's late in the release, we've expanded the 2nd list to 
be the same as the 1st with the exception of execve() not being in the 
2nd list.

>
> The problem occurs when the filters are executed in the kernel when a syscall
> is executed.  On each syscall the first filter will be executed and the action
> will either be ALLOW or TRAP/KILL, next the second filter will be executed and
> the action will either be ALLOW or TRAP/KILL; since the kernel always takes
> the most restrictive (lowest integer action value) action when multiple
> filters are specified, I think your double whitelist value is going to have
> some inherent problems.

That's something I hadn't thought of.  But TRAP and KILL won't exist 
together in our whitelists, and our 2nd whitelist is a subset of the 
1st.  So do you think there would still be problems?

> I might suggest an initial, fairly permissive
> whitelist followed by a follow-on blacklist if you want to disable certain
> syscalls.
>

I have to admit I'm nervous about this at this point in QEMU 1.3.  It's 
getting late in the cycle and we'd hoped to get this in earlier.  A more 
permissive whitelist is probably going to be the only way we'll 
successfully turn -sandbox on by default at this point in QEMU 1.3.

-- 
Regards,
Corey Bryant