From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUPI8-0006WL-Bj for qemu-devel@nongnu.org; Fri, 02 Nov 2012 18:00:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUPI4-0003Ih-Fk for qemu-devel@nongnu.org; Fri, 02 Nov 2012 18:00:40 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:37031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUPI4-0003Ia-BF for qemu-devel@nongnu.org; Fri, 02 Nov 2012 18:00:36 -0400 Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Nov 2012 18:00:35 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id DA330C9003E for ; Fri, 2 Nov 2012 18:00:31 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qA2M0V9M235438 for ; Fri, 2 Nov 2012 18:00:31 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qA2M0VWG006995 for ; Fri, 2 Nov 2012 18:00:31 -0400 Message-ID: <5094427D.9070906@linux.vnet.ibm.com> Date: Fri, 02 Nov 2012 18:00:29 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1350971732-16621-1-git-send-email-otubo@linux.vnet.ibm.com> <1350971732-16621-3-git-send-email-otubo@linux.vnet.ibm.com> <1451403.LXhkiqE48F@sifl> In-Reply-To: <1451403.LXhkiqE48F@sifl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Paul Moore Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, Eduardo Otubo 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 > > 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