[resending as tycho.nsa.gov bounced it the first time. Paul already responded so this is just for the archives] On Thu, 2010-03-25 at 18:06 -0400, Paul Moore wrote: > I thought QEMU/KVM was creating the socket and libvirtd was trying to connect > to it? If this is the case wouldn't it be a random virtual machine ... > > svirt_t:s3:c156 > > ... and a not-so-random libvirtd ... > > libvirtd_t:s0-s15:c0-c1023 > > ... trying to talk over a UNIX socket which is labeled svirt_t:s0 (on the > QEMU/KVM side) and libvirtd_t:s0-s15:c0-c1023 (on the libvirtd side)? I > agree, that could be a little wierd on the QEMU/KVM side, but if we use the > full MLS range for the child socket we end up with svirt:s0-s15:c0-c1023 on > the QEMU/KVM side and libvirtd_t:s0-s15:c0-c1023 on the libvirtd side; you'll > probably still need some MLS overrides on the QEMU/KVM side but you could at > least do something using the range. Yes, that is exactly what is happening. I find the label svirt:s0-s15:c0-c1023 abhorrent, but that's neither here nor there. MLS as an 'other' class citizen in the label makes me .... unhappy. So today we have: QEMU/KVM process: svirt_t:s3:c156 QEMU/KVM socket: svirt_t:s0-s15:c0-c1023 sds suggested we only copy the low part of the MLS context to the server label, which gives us: QEMU/KVM process: svirt_t:s3:c156 QEMU/KVM socket: svirt_t:s0:c0 which I don't think is any better as we still have to needlessly use MLS overrides which pretty much destroys the whole usefulness of vm isolation here. This is why I suggested an mls_copy_subset function so things could 'work' if you have ranged objects on either the client or server side. It only 'works' today if the ranged object is on the server side..... -Eric -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
