On Tuesday 30 March 2010 02:39:05 pm Paul Moore wrote: > On Tuesday 30 March 2010 02:23:33 pm Daniel J Walsh wrote: > > On 03/30/2010 02:20 PM, Eric Paris wrote: > > > On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote: > > >> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote: > > >>> Paul you are suggesting that I write a MLS rule that says > > >>> > > >>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain > > >>> sockets. > > >>> > > >>> Which would allow > > >>> > > >>> svirt_t:s0 to talk to svirt_t:s1 Which seems very broken to me. > > >> > > >> Well, based on the domains that were reported earlier in the thread > > >> ... > > >> > > >>> # ps -eZ | grep virt > > >>> system_u:system_r:virtd_t:s0-s15:c0.c1023 27344 ? 05:34:47 libvirtd > > >>> system_u:system_r:svirt_t:s0:c1 28549 ? 00:00:01 qemu-kvm > > >> > > >> ... I think you just need to write policy that allows > > >> "virtd_t:ANYLEVEL" and "svirtd_t:ANYLEVEL" to communicate; you > > >> shouldn't need to allow "svirt_t:ANYLEVEL" to communicate with > > >> "svirt_t" since only qemu-kvm is running as "svirt_t" and you are > > >> trying to get qemu-kvm and libvirtd to talk. > > > > > > The QEMU/KVM "server child socket" gets labeled svirt_t:s0-s15:c0-c1023 > > > (type of svirt_t and level of the peer, libvirtd_t) So svirt_t needs > > > to talk to svirt_t. That's the whole issue..... > > > > > > -Eric > > > > Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is > > easy > > > > allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the > > problem Since I end up allowing all svirt_t to talk to all svirt_t, No > > MLS controls at all. > > Maybe I'm just not thinking straight right now but if QEMU creates the > server socket, the server's parent socket should be labeled svirt_t:s0:c1. > When libvirtd tries to connect its client socket should be labeled > virtd_t:s0- s15:c0.c1023 and the resulting server child socket should be > labeled svirt_t:s0:c1 ... ah, okay, nevermind, I'm stupid. I'm thinking > along the lines of per-socket/message access controls, e.g. > selinux_sock_rcv_skb(), which don't apply here, it is all socket-to-socket > controls. > > It would seem to me that the best near term option is to fix the UNIX > domain socket as discussed previously (I'm half-done with that, got > sidetracked by this discussion as some RCU fixes) and add > setsockcreatecon() support for UNIX domain sockets (not sure why we don't > support that now). With that in place, libvirtd would do a > setsockcreatecon(self:QEMU_MLS_LABEL) before it connected to the QEMU > instance then the QEMU child socket would be labeled correctly and > everyone should be happy. I think it also makes sense given that libvirtd > is running syslo-syshi and the QEMU instances are running with very > specific MLS labels. Nevermind again, looking at the code it does look like setsockcreatecon() should work for UNIX domain sockets in the current code base ... anyway, I'd still go with the setsockcreatecon() approach. I'll work on getting an RFC class UNIX socket patch out today. -- 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.
