Re: RFC: virtual network access control

[Harry Butterworth <harry@hebutterworth.freeserve.co.uk>]

On Fri, 2006-07-28 at 10:17 -0400, Reiner Sailer wrote:
> 
> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 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
naive.

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