[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-ho
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd |
Date: |
Wed, 02 May 2012 10:20:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
Am 01.05.2012 22:25, schrieb Anthony Liguori:
> Thanks for sending this out Stefan.
>
> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
>> Libvirt can take advantage of SELinux to restrict the QEMU process and
>> prevent
>> it from opening files that it should not have access to. This improves
>> security because it prevents the attacker from escaping the QEMU process if
>> they manage to gain control.
>>
>> NFS has been a pain point for SELinux because it does not support labels
>> (which
>> I believe are stored in extended attributes). In other words, it's not
>> possible to use SELinux goodness on QEMU when image files are located on NFS.
>> Today we have to allow QEMU access to any file on the NFS export rather than
>> restricting specifically to the image files that the guest requires.
>>
>> File descriptor passing is a solution to this problem and might also come in
>> handy elsewhere. Libvirt or another external process chooses files which
>> QEMU
>> is allowed to access and provides just those file descriptors - QEMU cannot
>> open the files itself.
>>
>> This series adds the -open-hook-fd command-line option. Whenever QEMU needs
>> to
>> open an image file it sends a request over the given UNIX domain socket. The
>> response includes the file descriptor or an errno on failure. Please see the
>> patches for details on the protocol.
>>
>> The -open-hook-fd approach allows QEMU to support file descriptor passing
>> without changing -drive. It also supports snapshot_blkdev and other commands
>> that re-open image files.
>>
>> Anthony Liguori<address@hidden> wrote most of these patches. I added a
>> demo -open-hook-fd server and added some small fixes. Since Anthony is
>> traveling right now I'm sending the RFC for discussion.
>
> What I like about this approach is that it's useful outside the block layer
> and
> is conceptionally simple from a QEMU PoV. We simply delegate open() to
> libvirt
> and let libvirt enforce whatever rules it wants.
>
> This is not meant to be an alternative to blockdev, but even with blockdev, I
> think we still want to use a mechanism like this even with blockdev.
What does it provide on top?
This doesn't look like something that I'd like a lot. qemu should be
able to continue to run no matter what the management tool does, whether
it responds to RPCs properly or whether it has crashed. You need a
really good use case for the RPC that cannot be covered otherwise in
order to justify this.
Kevin
- Re: [Qemu-devel] [libvirt] [RFC 5/5] Example -open-hook-fd server, (continued)
- Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd,
Kevin Wolf <=
- Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Daniel P. Berrange, 2012/05/02
- Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Kevin Wolf, 2012/05/02
- Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Daniel P. Berrange, 2012/05/02
- Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Paolo Bonzini, 2012/05/02
- Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Anthony Liguori, 2012/05/03
Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Daniel P. Berrange, 2012/05/02
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Zhi Yong Wu, 2012/05/03