From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZgzB-0000aI-6i for qemu-devel@nongnu.org; Sun, 11 Dec 2011 05:50:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZgzA-0002z0-1T for qemu-devel@nongnu.org; Sun, 11 Dec 2011 05:50:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZgz9-0002yp-NU for qemu-devel@nongnu.org; Sun, 11 Dec 2011 05:50:23 -0500 Message-ID: <4EE48ADA.9000908@redhat.com> Date: Sun, 11 Dec 2011 12:50:02 +0200 From: Dor Laor MIME-Version: 1.0 References: <4EDFAF91.4070904@linux.vnet.ibm.com> <4EDFB4F0.70406@codemonkey.ws> <4EDFBF56.9030607@linux.vnet.ibm.com> <4EDFC1F3.1080900@codemonkey.ws> <1323291290.2486.13.camel@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Device sandboxing Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , wad@chromium.org, Richa Marwaha , Corey Bryant , Michael Halcrow , qemu-devel@nongnu.org, Eric Paris , Paul Moore , George Wilson , Avi Kivity , Amit Shah , Ashley D Lai , Eduardo Terrell Ferrari Otubo , Lee Terrell On 12/08/2011 11:40 AM, Stefan Hajnoczi wrote: > On Wed, Dec 7, 2011 at 8:54 PM, Eric Paris wrote: >> On Wed, 2011-12-07 at 13:43 -0600, Anthony Liguori wrote: >>> On 12/07/2011 01:32 PM, Corey Bryant wrote: >> >>>> That would seem like the logical approach. I think there may be new mode 2 >>>> patches coming soon so we can see how they go over. >>> >>> I'd like to see what the whitelist would need to be for something like QEMU in >>> mode 2. My biggest concern is that the whitelist would need to be so large that >>> the practical security what's all that much improved. >> >> When I prototyped my version of seccomp v2 for qemu a while back I did >> it by only looking at syscalls after inital setup was completed (aka the >> very last thing before main_loop() was to lock it down). My list was >> much sorter than even these: >> >> + __NR_brk, >> + __NR_close, >> + __NR_exit_group, >> + __NR_futex, >> + __NR_ioctl, >> + __NR_madvise, >> + __NR_mmap, >> + __NR_munmap, >> + __NR_read, >> + __NR_recvfrom, >> + __NR_recvmsg, >> + __NR_rt_sigaction, >> + __NR_select, >> + __NR_sendto, >> + __NR_tgkill, >> + __NR_timer_delete, >> + __NR_timer_gettime, >> + __NR_timer_settime, >> + __NR_write, >> + __NR_writev, >> >> There is simple obvious negligible overhead value here, but every >> proposal I know of, including mine, has been shot down by Ingo. Ingo's >> proposal is much more work, more overhead, but clearly more flexible. >> His suggestions (and code based on those suggestions from others) has >> been shot down by PeterZ. >> >> So I feel like seccomp v2 is between a rock and a hard place. We have >> something that works really well, and could be a huge win for all sorts >> of programs, but we don't seem to be able to get anything past the >> damned if you do, damned if you don't nak's..... >> >> (There's also a cgroup version of seccomp proposed, but I'm guessing it >> will go just about as far as all the other versions) > > Still, these sorts of situations are overcome all the time. Sometimes > it takes a while and several LWN.net articles about the drama but at > the end things can be worked out. > > If we want to discuss the specifics of mode 2 and especially what Ingo > or Peter think then I think we should do it in a forum where they > participate. Maybe their positions have changed. Will, little bird whispered that you'll going to send another iteration w/ higher acceptance chances. Where do we stand w/ it? Can you please elaborate on it chance to get merged? > > Stefan >