On Tue, 2010-03-30 at 15:31 -0400, Daniel J Walsh wrote:
> On 03/30/2010 03:22 PM, Paul Moore wrote:
> > On Tuesday 30 March 2010 03:13:29 pm Daniel J Walsh wrote:
> >
> >> On 03/30/2010 02:56 PM, Paul Moore wrote:
> >>
> >>> 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.
> >>>
> >> With that change both ends of the socket would be
> >>
> >> svirt_t:level1 and svirt_t:level1
> >>
> >> or
> >>
> >> virtd_t:level1 and svirt_t:level1
> >>
> > I believe that you should see the following:
> >
> > QEMU: svirt_t:s0:c1 (parent socket) and svirt_t:s0:c1 (child socket)
> >
> > libvirtd: virtd_t:s0:c1 (client socket)
> >
> >
> libvirt would have to execute
>
> setsockcreatecon("system_u:system_r:svirt_t:s0:c1")
> Then connect to the socket?
No, libvirt would use its own context and only modify the MLS part to
match the target qemu instance. And it would call setsockcreatecon()
before creating the client socket.
--
Stephen Smalley
National Security Agency
--
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.
