On Friday, February 22, 2013 02:54:43 PM Andy King wrote:

Hi Paul,

quoted

to see if anyone had any strong feelings on this approach (either good or
bad).  Here is what I am proposing, and currently working on ...

* Add a LSM secid/blob to the vmci_datagram struct

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?

Either way, we should be able to work around this, it would just be cleaner if 
we could add it to the datagram directly.

It's also not entirely clear to me how this will work in a heterogeneous
environments.  What if there's a Linux guest running on a Windows host,
or vice-versa?

I maybe missing something here, but VMCI never leaves the physical host system 
correct?  It doesn't get tunneled over some external network does it?

Assuming it stays on the physical host system then we don't really care about 
a Windows host in this context do we?  From a guests point of view it doesn't 
really matter, the kernel handles all of the labeling and access control; the 
guests create their AF_VSOCKS as they normally would.

I'll take a closer read at the rest of your mail, but I think we need to
address the above first.

I think there is some confusion about VMCI - which is almost surely on my end 
- and what I'm trying to accomplish with the labeling, perhaps by answering 
the above questions you can help me gain a better understanding and we can 
sort things out.

Thanks.

-- 
paul moore
security and virtualization @ redhat