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
|
Home