From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjX27-0001zv-7U for qemu-devel@nongnu.org; Thu, 21 Nov 2013 11:23:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjX1y-0005n2-9y for qemu-devel@nongnu.org; Thu, 21 Nov 2013 11:23:11 -0500 Received: from e24smtp05.br.ibm.com ([32.104.18.26]:33715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjX1x-0005gZ-SB for qemu-devel@nongnu.org; Thu, 21 Nov 2013 11:23:02 -0500 Received: from /spool/local by e24smtp05.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 21 Nov 2013 14:22:41 -0200 Received: from d24relay03.br.ibm.com (d24relay03.br.ibm.com [9.13.184.25]) by d24dlp01.br.ibm.com (Postfix) with ESMTP id 0C5B13520065 for ; Thu, 21 Nov 2013 11:22:39 -0500 (EST) Received: from d24av04.br.ibm.com (d24av04.br.ibm.com [9.8.31.97]) by d24relay03.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rALGMRXx33620130 for ; Thu, 21 Nov 2013 14:22:28 -0200 Received: from d24av04.br.ibm.com (localhost [127.0.0.1]) by d24av04.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rALGMcHq029908 for ; Thu, 21 Nov 2013 14:22:38 -0200 Message-ID: <528E3348.2010502@linux.vnet.ibm.com> Date: Thu, 21 Nov 2013 14:22:32 -0200 From: Eduardo Otubo MIME-Version: 1.0 References: <1382440906-3852-1-git-send-email-otubo@linux.vnet.ibm.com> <20131030100439.GD11994@stefanha-thinkpad.redhat.com> <528E2343.7030008@redhat.com> <40741416.pCfWYrZXGU@sifl> In-Reply-To: <40741416.pCfWYrZXGU@sifl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Moore Cc: Paolo Bonzini , coreyb@linux.vnet.ibm.com, qemu-devel , Anthony Liguori , Stefan Hajnoczi On 11/21/2013 01:48 PM, Paul Moore wrote: > On Thursday, November 21, 2013 04:14:11 PM Paolo Bonzini wrote: >> Il 30/10/2013 11:04, Stefan Hajnoczi ha scritto: >>> On Wed, Oct 23, 2013 at 12:42:34PM -0200, Eduardo Otubo wrote: >>>> On 10/22/2013 11:00 AM, Anthony Liguori wrote: >>>>> On Tue, Oct 22, 2013 at 12:21 PM, Eduardo Otubo >>>>> >>>>> wrote: >>>>>> Inverting the way sandbox handles arguments, making possible to have no >>>>>> argument and still have '-sandbox on' enabled. >>>>>> >>>>>> Signed-off-by: Eduardo Otubo >>>>>> --- >>>>>> >>>>>> The option '-sandbox on' is now used by default by virt-test[0] -- it >>>>>> has been merged into the 'next' branch and will be available in the >>>>>> next release, meaning we have a back support for regression tests if >>>>>> anything breaks because of some missing system call not listed in the >>>>>> whitelist. >>>>>> >>>>>> This being said, I think it makes sense to have this option set to 'on' >>>>>> by >>>>>> default in the next Qemu version. It's been a while since no missing >>>>>> syscall is reported and at this point the whitelist seems to be pretty >>>>>> mature. >>>>>> >>>>>> [0] - >>>>>> https://github.com/autotest/virt-test/commit/50e1f7d47a94f4c770880cd8e >>>>>> c0f18365dcba714>>> >>>>> This breaks hot_add of a network device that uses a script= argument, >>>>> correct? >>>>> >>>>> If so, this cannot be made default. >>>> >>>> Anthony, I believe you're talking about the blacklist feature. This >>>> is the old whitelist that is already upstream and it does not block >>>> any network device to be hot plugged. >>> >>> The following fails to start here (the shell hangs and ps shows QEMU is >>> a process): >>> >>> qemu-system-x86_64 -sandbox on -enable-kvm -m 1024 -cpu host \ >>> >>> -drive if=virtio,cache=none,file=test.img >> >> Easier-to-debug failures are another prerequisite for enabling the >> sandbox by default, I think. I've already sent a patch for a "debug mode" in the past. It was denied because of two main points: (1) Anthony was looking for a more solid and closed solution for sandboxing. A "debug" or "learning" mode would be too much exposure of the attack surface. (2) Debug mode was changing the Qemu's sig mask in a way that it was breaking it. And besides, at that time, there were too many linked libraries that would interfere on this sig handling, so we gave up on this feature. > > I believe I've posted this information before, but just in case ... > > IMHO, it is really not that hard to debug a seccomp failure; the first step is > to look for the failure in the audit log or syslog. If you are on a > Fedora/RHEL based system you are most likely running audit, so finding the > seccomp failures are quite simple with the 'ausearch' command: > > # ausearch -m SECCOMP > ---- > time->Wed Nov 20 09:52:08 2013 > type=SECCOMP msg=audit(1384912328.482:6656): auid=0 uid=0 gid=0 ses=854 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=12087 > comm="qemu-kvm" sig=31 syscall=62 compat=0 ip=0x7f7a1d2abc67 code=0x0 > > ... if you are using syslog, feel free to use whatever tool you prefer, e.g. > grep, less, etc. > > Once you have the syscall number, "syscall=62", in the audit message above, > you can use the 'scmp_sys_resolver' to resolve the number into a name: > > # scmp_sys_resolver 62 > kill > > The 'scmp_sys_resolver' tool is part of the libseccomp-devel package on > Fedora/RHEL based systems, it may be packaged differently on other > distributions. > > I'm always open to suggestions on how to improve the development/debugging > process, so if you have any ideas please let me know. Also, I've been working on some improvements on virt-test side. I'm trying to make it report the illegal system call using audit log and libseccomp as source of information. This way a simple run could identify missing system calls for the whitelist. -- Eduardo Otubo IBM Linux Technology Center