From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPLRq-000063-5V for qemu-devel@nongnu.org; Tue, 01 May 2012 18:21:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPLRo-0002F4-3p for qemu-devel@nongnu.org; Tue, 01 May 2012 18:21:29 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:61763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPLRn-0002Ep-V0 for qemu-devel@nongnu.org; Tue, 01 May 2012 18:21:28 -0400 Received: by obbwd20 with SMTP id wd20so29264obb.4 for ; Tue, 01 May 2012 15:21:25 -0700 (PDT) Message-ID: <4FA061E2.70308@codemonkey.ws> Date: Tue, 01 May 2012 17:21:22 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1335886307-27586-1-git-send-email-stefanha@linux.vnet.ibm.com> <4FA046C6.5080909@us.ibm.com> <4FA0598E.1040408@linux.vnet.ibm.com> <4FA05B63.3090301@codemonkey.ws> <4FA0608A.7070800@redhat.com> In-Reply-To: <4FA0608A.7070800@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , libvir-list@redhat.com, Corey Bryant , qemu-devel@nongnu.org On 05/01/2012 05:15 PM, Eric Blake wrote: > On 05/01/2012 03:53 PM, Anthony Liguori wrote: > >>> I think (correct me if I'm wrong) libvirt should be aware of any file >>> that qemu >>> asks it to open. So from a security point of view, libvirt can prevent >>> opening a >>> file if it isn't affiliated with the guest. >> >> Right, libvirt can maintain a whitelist of files QEMU is allowed to open >> (which is already has because it needs to label these files). > > Indeed. > >> The only >> complexity is that it's not a straight strcmp(). The path needs to be >> (carefully) broken into components with '.' and '..' handled >> appropriately. But this shouldn't be that difficult to do. > > Libvirt would probably canonicalize path names, both when sticking them > in the whitelist, and in validating the requests from qemu - agreed that > it's not difficult. > > More importantly, libvirt needs to start tracking the backing chain of > any qcow2 or qed file as part of the domain XML; and operations like > 'block-stream' would update not only the chain, but also the whitelist. > In the drive-reopen case, this means that libvirt would have to be > careful when to change labeling Would you give QEMU open access or change the way you label to only allow read/write access? I think the later is probably the better approach. So presumably, you'll need to adjust the sVirt policy too... You'll need to detect if a file is on NFS too and figure out what the default label is that was given so you can build the rules correctly. Regards, Anthony Liguori