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

Martin Kletzander mkletzan at redhat.com
Mon Jul 27 15:24:39 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.

I think we can say this won't "just work" unless the user sets
<seclabel> for the shmem properly or will turn off relabelling.
Libvirt must be the one to create the shm in order to properly audit
it and in case the shm is accessible by multiple QEMU instances, then
that needs to be audited as well.  That's according to security guys,
because that deals with the separation problem the same way as with
shared disks for example.

>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.
>|: 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 :|
>libvir-list mailing list
>libvir-list at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150727/6467f325/attachment-0001.sig>

More information about the libvir-list mailing list