On 07/28/2015 12:05 AM, Daniel P. Berrange wrote:
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@xxxxxxxxxx> 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.
libvirt still need fix the issues when use shmem device without
server(that is why i want manage the shmem resource ):
1. qemu won't unlink the share memory object after exit, and when we
restart the guest which use the old
shmem device name but size is bigger than old shmem device, qemu will
forbid guest start. then user need unlink the shm obj by themselves or
give a new name to the shmem device (this will leak the shm obj).
2. if let qemu create shm obj the label will depend on qemu process
label and like this:
-rwxrwxr-x. qemu qemu system_u:object_r:svirt_tmpfs_t:s0 my_shmem1
This label is not under libvirt control, and if the user want only one
guest use this (for host-guest connect) , the label is not good enough.
3. it will be better if we offer a way to users to specify the label by
themselves, because we cannot know how the user will use the shmem
device, so the label maybe not correct in some case.
So i wrote some helper to manage the shmem device resource to solve 3
issues, ivshmem server selinux label is a small part of them, i could
remove that part in a new version, i think the first and second issue
still need fix.
Thanks a lot for your review and advise.
Regards,
Daniel
Luyao
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list