[libvirt] [PATCH 0/4] manage the shmem device source

Daniel P. Berrange berrange at redhat.com
Mon Jul 27 16:05:51 UTC 2015


On Mon, Jul 27, 2015 at 03:40:36PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 27, 2015 at 04:09:01PM +0200, Marc-André Lureau wrote:
> > Hi Luyao
> > 
> > On Thu, Jul 23, 2015 at 12:13 PM, Luyao Huang <lhuang at redhat.com> wrote:
> > > But the problem is we cannot change the running shm-server process label,
> > > We need wait ivshmem-server to be a part of qemu progrem, then setup the
> > > ivshmem-server by libvirt. we cannot do nothing for the ivshmem-server right now.
> > 
> > ivshmem-server is going to be a separate server process, not part of
> > qemu process.
> > 
> > Is it enough if ivshmem-server is started by libvirt to solve the selinux issue?
> > 
> > What's missing to get started to support it with libvirt?
> 
> The complexity arises when multiple QEMUs want to connect to the same
> memory region. Each QEMU has its own unique SELinux label (eg something
> like svirt_t:s0:c352,c850 with random category values) So there is
> no single SElinux label you can give to an ivshmem server process to
> let it "just work" with multiple QEMUs, unless we chose to effectively
> just let any QEMU connect whatsoever by running ivmshmem-server under
> svirt_t:s0:c0.c1023 which removes all isolation between the guests.
> This is label we use for disk images which must be shared between
> QEMUs currently, but long term we're going to need to come up with
> a way to allow concurrent access but kep separation. At that point
> we'll likely need to implement the ivmshmem server as part of the
> libvirt project itself, so we can deal with SELinux.
> 
> Until that point though, I think the simplest thing todo is to get
> an addition to the SELinux policy. We want to have
> 
>   - ivshmem-server running under a 'qemu_shmemd_t' type
>   - ivshmem-server UNIX domain socket labeled 'qemu_shmemd_sock_t'
>   - svirt_t permitted to connect to any qemu_shmemd_sock_t
> 
> this doesn't require any code in libvirt or QEMU - should be possible
> todo it entirely in selinux policy rules.

Just for clarification - this means I am NACK'ing all 4 patches
here, because I don't think any of this extra code is needed.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list