Re: [Xen-devel] RFC: virtual network access control - Harry Butterworth - com.xensource.lists.xen-devel

12 messages in com.xensource.lists.xen-develRe: [Xen-devel] RFC: virtual network ...

From	Sent On	Attachments
Reiner Sailer	27 Jul 2006 13:51
Caitlin Bestler	27 Jul 2006 13:57
Keir Fraser	28 Jul 2006 02:18
Reiner Sailer	28 Jul 2006 07:17
Keir Fraser	28 Jul 2006 07:30
Harry Butterworth	28 Jul 2006 07:47
Reiner Sailer	28 Jul 2006 07:55
Keir Fraser	28 Jul 2006 08:05
Gerd Hoffmann	28 Jul 2006 08:12
Reiner Sailer	28 Jul 2006 09:30
Reiner Sailer	28 Jul 2006 12:49
Mike Day	28 Jul 2006 16:42

Subject:	Re: [Xen-devel] RFC: virtual network access control
From:	Harry Butterworth (har...@hebutterworth.freeserve.co.uk)
Date:	07/28/2006 07:47:29 AM
List:	com.xensource.lists.xen-devel

On Fri, 2006-07-28 at 10:17 -0400, Reiner Sailer wrote:

Keir Fraser <Keir...@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