From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjrss-0005l9-Kb for qemu-devel@nongnu.org; Fri, 22 Nov 2013 09:39:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vjrsm-0003lU-7o for qemu-devel@nongnu.org; Fri, 22 Nov 2013 09:39:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:65232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjrsl-0003ks-Ua for qemu-devel@nongnu.org; Fri, 22 Nov 2013 09:38:56 -0500 From: Paul Moore Date: Fri, 22 Nov 2013 09:38:50 -0500 Message-ID: <6388825.6pMDJVlAMn@sifl> In-Reply-To: <20131122103441.GA24388@stefanha-thinkpad.redhat.com> References: <1382440906-3852-1-git-send-email-otubo@linux.vnet.ibm.com> <20131030100439.GD11994@stefanha-thinkpad.redhat.com> <20131122103441.GA24388@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: coreyb@linux.vnet.ibm.com, qemu-devel , Anthony Liguori , Eduardo Otubo On Friday, November 22, 2013 11:34:41 AM Stefan Hajnoczi wrote: > IMO this seccomp approach is doomed since QEMU does not practice > privilege separation. QEMU is monolithic so it's really hard to create > a meaningful sets of system calls. I'm a big fan of decomposing QEMU, but based on previous discussions there seems to be a lot of fear from the core QEMU folks around decomposition; enough that I'm not sure it is worth the time and effort at this point to pursue it. While I agree that a decomposed QEMU would be able to make better use of syscall filtering (and LSM/SELinux protection, and ...) I don't believe it means syscall filtering is a complete lost cause with a monolithic QEMU. Any improvement you can make, no matter how small, is still and improvement. > To avoid breaking stuff you need to be too liberal, defeating the purpose of > seccomp. Even if you can only disable a few syscalls you are still better off than you were before. Could it be done better, of course it could, but it doesn't mean you shouldn't try for some benefit. > For each QEMU command-line there may be a different set of syscalls that > should be allowed/forbidden. I'm not sure if you missed it or not, but I had an email exchange with Eduardo on this list about making the syscall whitelist a bit more "intelligent" and dependent on what functionality was enabled for a given QEMU instance. This should help a bit with the problems you are describing. > The existing approach clearly doesn't support the full range of options > that users specify on the command-line. Bugs. It will get fixed in time with more testing/debugging. Eduardo is working on improving the testing and RH's QA folks are working hard to shake out the bugs too. I just posted another bug fix patch to the whitelist a few days ago. > So I guess the options are: > > 1. Don't make it the default since it breaks stuff but use it for very > specific scenarios (e.g. libvirt use cases that have been well tested). In my opinion, I think it was probably a bit premature to make enable it by default, but at some point in the future I think we do need to do this. > 2. Provide a kind of syscall set for various QEMU options and apply the > union of them at launch. This still seems fragile but in theory it > could work. This is what I was discussing above. I think this is likely the next big improvement. -- paul moore security and virtualization @ redhat