Re: svirt on MLS has strange AVC.

[Paul Moore <paul.moore@hp.com>]

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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.