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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCHv2 3/4] Support for "double whitelist" filters
Date: Fri, 02 Nov 2012 17:01:50 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Paul Moore <address@hidden> writes:

> 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 

qemu.org is up, just having DNS problems.  Use git.qemu-project.org
instead and you should be fine.

Regards,

Anthony Liguori

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