On Monday, February 25, 2013 08:29:46 AM Gerd Hoffmann wrote:

  Hi,

Hello.

quoted

quoted

I think perhaps this is the wrong layer at which to embed this.  Think
of that structure as an ethernet header, with VMCI being ethernet; it's
what the device (and the hypervisor and peer) understand.  So this
really cannot be changed.

Hmmm, so can VMware/VMCI-enabled guests send vmci_datagram packets
directly into the kernel?  It isn't wrapped by things like AF_VSOCK? If
that is the case, then yes, we'll probably need to add a thin wrapper
struct to carry the security label; similar to the control packets but not
quite, as we have data to deal with unlike the control packets.  However,
if vmci_datagram is an internal only structure, why not add the extra
field?

vmci_datagram is part of the guest/host ABI I think.

Data flow looks like this:

(1) guest application opens a AF_VSOCK socket
(2) guest sends data as usual (say send syscall).
(3) vsock core hards over the packet to the transport layer

    (only vmci atm, but we wanna add virtio here).

(4) transport layer passes data to the hypervisor (vmci uses a

    virtual pci device for that, virtio will do the same).
...

Okay, I think I found the core of my misunderstanding: I was under the 
impression that the AF_VSOCK layer lived in the host kernel, not the guest 
kernel.

With the VS_VSOCK layer in the guest kernel this all becomes much less 
interesting.  I'll take another look today, but I think the only changes we 
probably want to make are with SELinux - the "virt_socket" object class - so 
we can control which applications in the guest can use AF_VSOCK sockets.  I 
don't think we will need any changes to Smack but I'll take a closer look.  
Also, all the changes I suggested earlier to VMCI aren't necessary; as you and 
Andy point out, this is the wrong layer - we can't do a whole lot of 
meaningful enforcement in the guest.

Thanks for the clarification.
-Paul

-- 
paul moore
security and virtualization @ redhat