From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjryX-0008RT-T9 for qemu-devel@nongnu.org; Fri, 22 Nov 2013 09:44:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjryR-0005QQ-Jg for qemu-devel@nongnu.org; Fri, 22 Nov 2013 09:44:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjryR-0005Q5-9i for qemu-devel@nongnu.org; Fri, 22 Nov 2013 09:44:47 -0500 From: Paul Moore Date: Fri, 22 Nov 2013 09:44:42 -0500 Message-ID: <3468561.4aYf2ZG3eq@sifl> In-Reply-To: <20131122103931.GB24388@stefanha-thinkpad.redhat.com> References: <1382440906-3852-1-git-send-email-otubo@linux.vnet.ibm.com> <40741416.pCfWYrZXGU@sifl> <20131122103931.GB24388@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Stefan Hajnoczi Cc: Paolo Bonzini , coreyb@linux.vnet.ibm.com, qemu-devel , Anthony Liguori , Eduardo Otubo On Friday, November 22, 2013 11:39:31 AM Stefan Hajnoczi wrote: > On Thu, Nov 21, 2013 at 10:48:58AM -0500, Paul Moore wrote: > > I'm always open to suggestions on how to improve the development/debugging > > process, so if you have any ideas please let me know. > > The failure mode is terrible: Glad to see you don't feel strongly about things. > "The following fails to start here (the shell hangs and ps shows QEMU > is a process)" > > When a process dies the shell prints a warning. That alerts the user > and prompts them to take further steps. > > Hanging the shell is a really bad way to fail. We can't expect users to > begin searching logs for audit failures. They probably don't even know > about audit or seccomp. First things first, if a normal user hits a seccomp failure I consider it to be a bug, and to be honest, I've seen much nastier, much more subtle bugs than an inadvertent seccomp "death". In a perfect world only developers would run into this problem and I would expect developers to be smart enough to figure out what is going on. Getting past that, if seccomp is configured to kill the process when it violates the filter rules there isn't much else we can do; the kernel kills the process and then the rest of userspace, e.g. the shell/libvirt/etc., does whatever it does. We have very little control over things. > Is it possible to produce output when a seccomp violation takes place? See the earlier comments from Eduardo about his attempts in this area. -- paul moore security and virtualization @ redhat