From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Z3B-0007DT-32 for qemu-devel@nongnu.org; Sun, 12 Jan 2014 23:23:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2Z32-0002pM-I3 for qemu-devel@nongnu.org; Sun, 12 Jan 2014 23:22:57 -0500 Received: from mail-qc0-x231.google.com ([2607:f8b0:400d:c01::231]:61170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Z32-0002pD-D2 for qemu-devel@nongnu.org; Sun, 12 Jan 2014 23:22:48 -0500 Received: by mail-qc0-f177.google.com with SMTP id i8so2462573qcq.36 for ; Sun, 12 Jan 2014 20:22:48 -0800 (PST) Message-ID: <52D36A12.7090004@gmail.com> Date: Sun, 12 Jan 2014 23:22:42 -0500 From: "immersive.excel@gmail.com" MIME-Version: 1.0 References: <52D2EA57.7050905@gmail.com> <20140113041101.GC20389@stefanha-thinkpad.redhat.com> In-Reply-To: <20140113041101.GC20389@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] chroot jailing... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org Thanks! So it sounds like you're saying selinux is the only meaningful thing to try? Or do people ever bother to place qemu in chroot jails?? I seem to have gotten the impression that people use qemu-static to do this, but it appears to be more for offering secured access of a guest folder to the host OS; not so much for security... ======================== On 01/12/2014 11:11 PM, Stefan Hajnoczi wrote: > 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