[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > Sounds like you want to implement a primitive firewall in netback
> > simply to avoid a dependency on the existing mechanisms that Linux
> > That doesn't sound a good tradeoff to me, and I think it's unlikely
> > 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
> > netback is in a driver domain. Possibly we need to come up with
> > xenstore<->iptables interface (e.g., run an interfacing daemon in
> > 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
> Xen-devel mailing list
Xen-devel mailing list