This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] RFC: virtual network access control

On Fri, 2006-07-28 at 10:17 -0400, Reiner Sailer wrote:
> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote on 07/28/2006 05:18:30
> AM:
> > Sounds like you want to implement a primitive firewall in netback 
> > simply to avoid a dependency on the existing mechanisms that Linux
> has. 
> > That doesn't sound a good tradeoff to me, and I think it's unlikely
> to 
> > fly with the kernel maintainers.
> We are interested in controlling access based on the security labels
> of sender and receiver domains, not based on IP or other traditional
> firewall packet attributes. 
> > The only problem I can see with relying on iptables (other than 
> > requiring it to be installed) is that it becomes harder to configure
> if 
> > netback is in a driver domain. Possibly we need to come up with
> some 
> > xenstore<->iptables interface (e.g., run an interfacing daemon in
> the 
> > same domain as netback).
> We see other problems as well: IPtables seems to not see any of the
> ethernet-bridged packets. If you wanted to use IPtables then you  
> would need to replace the ethernet bridge with routing each packet. 

In the longer term I thought we wanted support for high-performance
networking direct from domU to domU.  In which case it seems to me that
networking is similar to the block case: domains derive from the
resource foundation in xenstore++, the user makes a request to the
xenstore++ code to connect the two domain resources together. xenstore++
does the role-based access checks and finds the protocol definition that
corresponds to a connection between two domains which would be a network
protocol.  xenstore++ sets up the connection.  All the same generic MAC
infrastructure in xenstore++ is reused for connections between two
domain resources in the same way that it is used for connections between
a domain resource and a block resource.

This solution eliminates the requirement for any special security code
in the net back and front drivers and for example lets users choose
whether to have a domain acting as a router using the standard Linux
infrastructure or whether to connect domains using point-to-point
connections or whether to have some combination.

As Keir says, there's an opportunity to create a standard, trusted,
stripped down router domain with a convenient interface exported to the
xen user API.

I don't really know much about networking though so maybe this is a bit

> Reiner
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list