From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Butterworth Subject: Re: RFC: virtual network access control Date: Fri, 28 Jul 2006 15:47:52 +0100 Message-ID: <1154098072.7710.34.camel@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Reiner Sailer Cc: xen-devel@lists.xensource.com, xense-devel@lists.xensource.com, Bryan D Payne List-Id: xen-devel@lists.xenproject.org On Fri, 2006-07-28 at 10:17 -0400, Reiner Sailer wrote: > > Keir Fraser 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