From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50343)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VGQ58-0007Zp-Sr
	for qemu-devel@nongnu.org; Mon, 02 Sep 2013 05:06:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VGQ4z-0002E9-Ir
	for qemu-devel@nongnu.org; Mon, 02 Sep 2013 05:05:58 -0400
Received: from mail-ea0-x235.google.com ([2a00:1450:4013:c01::235]:53641)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VGQ4z-0002Dt-3H
	for qemu-devel@nongnu.org; Mon, 02 Sep 2013 05:05:49 -0400
Received: by mail-ea0-f181.google.com with SMTP id d10so2209791eaj.40
	for <qemu-devel@nongnu.org>; Mon, 02 Sep 2013 02:05:47 -0700 (PDT)
Date: Mon, 2 Sep 2013 11:05:45 +0200
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20130902090545.GA947@stefanha-thinkpad.redhat.com>
References: <1377738272-3470-1-git-send-email-otubo@linux.vnet.ibm.com>
	<5220AA75.7080402@linux.vnet.ibm.com>
	<CAJSP0QUfkSOujKBmSqwa8mp-BXTy8h-kvo8Fyc6_htKJBj938g@mail.gmail.com>
	<5324254.5TBDVHLJVV@sifl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5324254.5TBDVHLJVV@sifl>
Subject: Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Moore <pmoore@redhat.com>
Cc: Corey Bryant <coreyb@linux.vnet.ibm.com>, wad@chromium.org, qemu-devel <qemu-devel@nongnu.org>, Eduardo Otubo <otubo@linux.vnet.ibm.com>

On Fri, Aug 30, 2013 at 11:42:34AM -0400, Paul Moore wrote:
> On Friday, August 30, 2013 05:23:45 PM Stefan Hajnoczi wrote:
> > On Fri, Aug 30, 2013 at 4:21 PM, Eduardo Otubo <otubo@linux.vnet.ibm.com> 
> wrote:
> > > On 08/29/2013 05:34 AM, Stefan Hajnoczi wrote:
> > >> On Wed, Aug 28, 2013 at 10:04:32PM -0300, 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().
> > >> 
> > >> -netdev tap,downscript=/path/to/script requires exec() in the QEMU
> > >> shutdown code path.  Will this work with seccomp?
> > > 
> > > I actually don't know, but I'll test that as well. Can you run a test with
> > > this patch and -netdev? I mean, if you're pointing that out you might have
> > > a scenario already setup, right?
> > 
> > I'm not having much luck running qemu.git/master with CONFIG_SECCOMP
> > on Fedora 19.  The GTK UI opens but I don't see the guest's display.
> > 
> > $ x86_64-softmmu/qemu-system-x86_64
> > [...GTK UI opens but QEMU is hung...]
> > 
> > strace shows the process is hung somehow and ps says it's <defunct>
> > although it never exited.
> > 
> > $ sudo cat /proc/5912/stack
> > [<ffffffff81061fda>] do_exit+0x6ca/0xa20
> > [<ffffffff810ef090>] __secure_computing+0xe0/0x240
> > [<ffffffff8101d722>] syscall_trace_enter+0x172/0x230
> > [<ffffffff816478c8>] tracesys+0x7e/0xe2
> > [<ffffffffffffffff>] 0xffffffffffffffff
> > 
> > Okay, so seccomp killed the process.
> > 
> > $ sudo cat /proc/5912/syscall
> > 29 0x0 0x1000 0x380 0x7fffbeb49380 0x0 0x0 0x7fffbeb495b8 0x7f6b72402657
> > 
> > $ git grep '\<29\>' arch/x86/include/generated/uapi/asm/unistd_64.h
> > #define __NR_shmget 29
> > 
> > Now it needs syscall 30.  I guess the whitelist is only designed for a
> > specific invocation that you are testing?
> 
> For future reference, it doesn't need to be that hard to identify when seccomp 
> has killed a process.  If you're running audit go ahead and check the audit 
> log:
> 
>  # ausearch -m SECCOMP
>  ----
>  time->Fri Aug 30 11:37:46 2013
>  type=SECCOMP msg=audit(1377877066.414:64): auid=0 uid=0 gid=0 ses=1
>  subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3787
>  comm="20-live-basic_d" sig=31 syscall=2 compat=0 ip=0x3a27ae6570 code=0x0
> 
> ... and notice the 'syscall' field which in this case happens to be '2'.  If 
> you have the 'scmp_sys_resolver' tool installed on your system (libseccomp-
> devel >= 2.1.0 on Fedora) you can then resolve the syscall number:
> 
>  # scmp_sys_resolver 2
>  open
> 
> It is also worth mentioning that while scmp_sys_resolver resolves syscalls for 
> the native architecture by default, it can resolve for any of the 
> architectures that libseccomp supports, see the manpage for details 
> (currently: x86, x86_64, x32, and arm).

Useful tips, thanks.

Stefan