From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Yrz-0003Kt-Ut for qemu-devel@nongnu.org; Sun, 12 Jan 2014 23:11:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2Yrr-00083a-Gf for qemu-devel@nongnu.org; Sun, 12 Jan 2014 23:11:23 -0500 Received: from mail-ea0-x22d.google.com ([2a00:1450:4013:c01::22d]:39800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Yrr-000820-AN for qemu-devel@nongnu.org; Sun, 12 Jan 2014 23:11:15 -0500 Received: by mail-ea0-f173.google.com with SMTP id o10so3047060eaj.32 for ; Sun, 12 Jan 2014 20:11:14 -0800 (PST) Date: Mon, 13 Jan 2014 12:11:01 +0800 From: Stefan Hajnoczi Message-ID: <20140113041101.GC20389@stefanha-thinkpad.redhat.com> References: <52D2EA57.7050905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D2EA57.7050905@gmail.com> Subject: Re: [Qemu-devel] chroot jailing... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "immersive.excel@gmail.com" Cc: qemu-devel@nongnu.org On Sun, Jan 12, 2014 at 02:17:43PM -0500, immersive.excel@gmail.com wrote: > Would there be any security benefits, without suffering any considerable > relative loss in performance, to (chroot) jailing qemu? Can it, > practically speaking, be done?? Would that be a partial safeguard > against virtual machine escapes? Or is it the case that if a virtual > machine escape takes place, then all bets are probably off? (i.e., you > probably have already pole-vaulted over any filesystem driver/partition > access control mechanisms...) Are there any articles or discussions that > I can be directed to about it? (my focus for now is 64 bit, Intel core > i7...) Are there specific suggestions and/or guidelines for attempting > to do so -or not?? Isolating QEMU can be useful to prevent exposing data on the host or from other guests. Production systems using libvirt often run QEMU unprivileged and use SELinux to restrict what resources the process has access to. This way a QEMU process that has been taken over still cannot get access to much besides the files it already has open, the network device it uses, etc. Stefan