From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUOnk-0000q6-Aa for qemu-devel@nongnu.org; Fri, 02 Nov 2012 17:29:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUOnf-0000wk-R6 for qemu-devel@nongnu.org; Fri, 02 Nov 2012 17:29:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUOnf-0000wb-GK for qemu-devel@nongnu.org; Fri, 02 Nov 2012 17:29:11 -0400 From: Paul Moore Date: Fri, 02 Nov 2012 17:29:07 -0400 Message-ID: <1451403.LXhkiqE48F@sifl> In-Reply-To: <1350971732-16621-3-git-send-email-otubo@linux.vnet.ibm.com> References: <1350971732-16621-1-git-send-email-otubo@linux.vnet.ibm.com> <1350971732-16621-3-git-send-email-otubo@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [PATCHv2 3/4] Support for "double whitelist" filters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo , coreyb@linux.vnet.ibm.com Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org 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 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