Re: [Xense-devel] Secure Network Communications Between Xen VMs

[Ramon Caceres <caceres@xxxxxxxxxx>]

Mike,

I'll add to Andrew's previous response (below) by describing what the 
current Deuterium prototype does.  By the way, the Deuterium paper is 
available at either of these URLs:

http://tinyurl.com/zbbc6
http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/eac6708db1c54cf38525710f005b7aff

Deuterium extends the Mandatory Access Control (MAC) facilities already in 
Xen to control communication between domains on different machines.  As 
Andrew mentioned, in Xen all network traffic to/from domUs goes through 
the local dom0, which can either bridge or route the traffic.  In 
Deuterium, we turn off the default bridging and use IP routing for all 
traffic.  Furthermore, we run SELinux in dom0 to provide additional MAC 
facilities above the hypervisor.

Let me walk through what happens to an individual IP packet, first without 
worrying about MAC.  When a domU sends an IP packet to a remote machine, 
the packet ends up in the IP layer of the local dom0.  We configure dom0 
to forward the packet over an IPSec tunnel to the remote machine.  We 
dynamically create IPSec tunnels as needed.

Now I'll describe how MAC is applied to the packet so that it is only 
forwarded if the MAC policy says it should.  In the implementation, there 
are actually three policies working together: the Xen policy, the SELinux 
policy, and the Labeled IPSec policy (Labeled IPSec is recent work by 
Jaeger et al.  that extends SELinux MAC to IPSec communication across a 
network).  We configure the three policies so that only domains of the 
same type/label can communicate, according to MAC Type Enforcement rules.

More specifically, we assign a Xen type/label to each domU.  We added code 
in dom0 to map these Xen labels to SELinux labels.  dom0 knows which domU 
sent the packet, so in a sense the packet has both a Xen and an SELinux 
label (although it doesn't physically carry any labels).  Finally, Labeled 
IPSec associates an SELinux label with each  tunnel endpoint and enforces 
that only packets with the correct implicit label can enter a tunnel. 

Similar processing is done on traffic arriving at a dom0 through an IPSec 
tunnel and destined for a local domU.  Namely, arriving packets implicitly 
acquire the label of the tunnel endpoint.   Our code in dom0 maps SELinux 
labels to Xen labels, and forwards the packet only if its implicit label 
matches that of the destination domain.  I hope it's clear that if we 
write the three MAC policies properly, only domains with the proper labels 
can communicate.

The above deals with traffic between Xen domains on different physical 
machines.  As part of our ongoing efforts in this area, we are working on 
securing traffic between domains on the same physical machine.   We'll 
report further developments in this forum.

I hope this answers your questions.

--Ramón
_____________________________
Ramón Cáceres
Research Staff Member
IBM T.J. Watson Research Center


"Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx> 
Sent by: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
05/09/2006 01:27 PM

To
bigschu <bigschu@xxxxxxxxxxxxxxxxxxx>
cc
Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject
Re: [Xense-devel] Secure Network Communications Between Xen VMs






Hi Mike,

> 1) By way of example, if domU1 on machine M1 is communicating with two
> other domains, domU2 and domU3 on machine M2, how does the
> hypervisor/ACM on M1 differentiate between inbound/outbound traffic
> destined only for domU2 or domU3 and ensure that traffic is routed to
> the proper domain?

Packet forwarding in Xen is handled on behalf of domU's by the Linux
forwarding code running in dom0.  Depending on the machine's set up,
it will either use the linux bridge (currently the default) or routing
code to forward packets.  Depending on which of these is used, dom0
demuxes received packets based on their MAC or IP address, and passes
them along to the appropriate domU.

> 2) Is all of the traffic between various domains encrypted to prevent
> eavesdropping via network sniffing?

Xen is generally unconcerned with the contents of the data that it is
forwarding.  One exception to this is the antispoof feature which
validates source IPs on transmit to ensure that they are valid.  There
is some code in the tools tree to provide VPN functionality between
VMs on different physical hosts.  It was written by Mike Wray at HP
and I'm not sure if it's been used by anyone recently.  In general, I
think we would generally view encryption as being an end-to-end thing
that's best handled within individual domUs.

> I've read the paper, "DeuTeRium -- A System for Distributed Mandatory
> Access Control" but it's not clear to me from the actual implementation
> examples and documentation how you set up the IPSEC labeled tunneling
> mechanism and ensure validation of all traffic passing between the
> various domains.

I can't seem to find a copy of this paper on the web, so this is
likely a question for Reiner. ;)

hth,
a.

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel