qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Moore
Subject: Re: [Qemu-devel] [PATCHv2 3/4] Support for "double whitelist" filters
Date: Fri, 02 Nov 2012 17:29:07 -0400
User-agent: KMail/4.9.2 (Linux/3.6.4-gentoo; KDE/4.9.2; x86_64; ; )

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 <address@hidden>

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.

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

-- 
paul moore
security and virtualization @ redhat




reply via email to

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