From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF1mk-0004lz-1D for qemu-devel@nongnu.org; Thu, 29 Aug 2013 08:57:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VF1me-00032l-1c for qemu-devel@nongnu.org; Thu, 29 Aug 2013 08:57:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF1md-00032d-Pd for qemu-devel@nongnu.org; Thu, 29 Aug 2013 08:57:07 -0400 From: Paul Moore Date: Thu, 29 Aug 2013 08:56:59 -0400 Message-ID: <2886554.JWDlXEmk61@sifl> In-Reply-To: <1377738272-3470-1-git-send-email-otubo@linux.vnet.ibm.com> References: <1377738272-3470-1-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] [PATCH] seccomp: adding a second whitelist List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: coreyb@linux.vnet.ibm.com, wad@chromium.org, qemu-devel@nongnu.org On Wednesday, August 28, 2013 10:04:32 PM Eduardo Otubo wrote: > Now there's a second whitelist, right before the vcpu starts. The second > whitelist is the same as the first one, except for exec() and select(). > > Signed-off-by: Eduardo Otubo We talked about this in a previous thread, but as a reminder, the kernel's seccomp BPF filter works by executing all of the loaded filters for each syscall and taking the least permissive action for all of the results. In other words, if one filter returns ALLOW for a given syscall and another filter returns KILL, the kernel will select the KILL action for the syscall. With that in mind, I think the best option is to keep the existing whitelist and instead of creating a second whitelist, create a second *blacklist* that removes the syscalls you don't want to allow anymore, e.g. exec() and select(). This approach should be easier to maintain and would result in less overhead in the kernel's seccomp evaluator (the blacklist filter would be much smaller than a second whitelist filter). -Paul -- paul moore security and virtualization @ redhat