On Thursday 25 March 2010 03:02:10 pm Eric Paris wrote: > On Thu, 2010-03-25 at 14:17 -0400, Stephen Smalley wrote: > > It seems to me that it really should only get the low/current level of > > the peer, not the full range, e.g. mls_context_cpy_low(), so that we > > don't turn a connection from a ranged subject into a fully ranged > > socket? This is an interesting question, and you could ask the same of INET connections where you have a ranged client peer label available. I guess my question is considering that the UNIX socket MLS constraints seem to follow the rest of the MLS constraint conventions (the low half of the range is used as the effective sensitivity label and the high half of the range is used as the cleared sensitivity label) what do you loose with the current implementation? I haven't thought about it enough to have an opinion yet ... > Is that even the best, by itself? We would still be in the same > situation except now we would have a random virtual machine > > svirt_t:s3:c156 > > trying to read/write to a socket with the label: > > svirt_t:s0:c0 > > since libvirtd_t is going to pretty much always be running: > > libvirtd_t:s0-s15:c0-1023 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. -- paul moore linux @ hp -- 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.
