Xen devel - Jul 2006 - RFC: virtual network access control

The problem: domain0 does not enforce the access control policy on network 
packets that it forwards between different user domains.

We would like to propose a solution that solves this problem now. Next 
generation security enhancements may present better ways to solve this 
problem and we are looking forward to contributing to them as well.

Looking at options for a solution for the current version of Xen, we 
propose netback as the place to enforce the policy. XM tools are not in 
the network path and do not resolve this problem. Therefore, this problem 
is different from the general resource access control problem (eg. 
blockback).

We also thought of extending packet filtering on MAC or IP level but it 
these options add new software package dependencies, e.g., ebtables or 
iptables. In addition, re-using existing iptables filters would require 
switching off the bridge and managing point-to-point rules for a 
potentially large number of user domains.

We appreciate feedback on the netback approach and we are open to other 
suggestions that solve this problem.

Reiner

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

xen-devel-bounces@lists.xensource.com wrote:
> The problem: domain0 does not enforce the access control
> policy on network packets that it forwards between different user
> domains. 
> 
Is there any reason why it should, beyond the degree
that it does so as a virtual bridge/router/switch?



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

> Looking at options for a solution for the current version of Xen, we 
> propose netback as the place to enforce the policy. XM tools are not 
> in the network path and do not resolve this problem. Therefore, this 
> problem is different from the general resource access control problem 
> (eg. blockback).
>
> We also thought of extending packet filtering on MAC or IP level but 
> it these options add new software package dependencies, e.g., ebtables 
> or iptables. In addition, re-using existing iptables filters would 
> require switching off the bridge and managing point-to-point rules for 
> a potentially large number of user domains.
>
> We appreciate feedback on the netback approach and we are open to 
> other suggestions that solve this problem.
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.

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).

  -- Keir


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

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.

Reiner

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

On 28 Jul 2006, at 15:17, Reiner Sailer wrote:
>  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.
But the access-control decision must ultimately be made based on 
network-packet attributes. At the level of packet forwarding you only 
have details like the IP address to base your decision on. Presumably 
you map that into the ''security label'' namespace, and thus
make your
decision. Well, you can do that at policy instantiation time, or 
network-interface creation time, by mapping from ''security
labels'' to
details such as IP addresses, and then poke down firewall rules.
>  > 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.
We support routing: we provide scripts out of the box for this, it''s 
just not the default (Ethernet bridging ''just works'' in many 
situations, which we think is an important consideration [and one that 
often works against the aims of the security conscious :-)]).

  -- Keir


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

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

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

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 07/28/2006 10:31:16 AM:
> >
> > 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.
> 
> But the access-control decision must ultimately be made based on 
> network-packet attributes. At the level of packet forwarding you only 
> have details like the IP address to base your decision on. Presumably 
> you map that into the ''security label'' namespace, and
thus make your
> decision. Well, you can do that at policy instantiation time, or 
> network-interface creation time, by mapping from ''security
labels'' to
> details such as IP addresses, and then poke down firewall rules.
We propose to make access control decisions for packets based on the 
domain id-s of sender and receiver (available in the netback interfaces). 
sHype/ACM already offers a hypercall to retrieve a policy decision based 
on two domain id-s.

This does not require to map static policy rules onto dynamic IP addresses 
/ MAC addresses or to rely on any packet content that is crafted in user 
domains (which the ACM does not trust).

> >  > 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.
> 
> We support routing: we provide scripts out of the box for this,
it''s
> just not the default (Ethernet bridging ''just works'' in
many
> situations, which we think is an important consideration [and one that 
> often works against the aims of the security conscious :-)]).
> 
>   -- Keir

We are concerned that there is a performance reason for not routing 
packets. We are interested in minimal overhead for security. We can''t 
avoid making access control decisions at some point in time (and caching 
it), but we try to avoid introducing dependencies on configurations that 
imply additional overhead.

Reiner

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

On 28 Jul 2006, at 15:56, Reiner Sailer wrote:
> We propose to make access control decisions for packets based on the 
> domain id-s of sender and receiver (available in the netback 
> interfaces). sHype/ACM already offers a hypercall to retrieve a policy 
> decision based on two domain id-s.
>
> This does not require to map static policy rules onto dynamic IP 
> addresses / MAC addresses or to rely on any packet content that is 
> crafted in user domains (which the ACM does not trust).
You mean tag a packet when it arrives from a source domain and then use 
that if/when it boomerangs back at you on a different virtual 
interface?

In terms of cost, an extra hypercall per packet will have measurable 
cost, at least in CPU usage, for high-bandwidth network transfers.

  -- Keir


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

Reiner Sailer wrote:
> 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.
> 
> 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.
You want CONFIG_BRIDGE_NETFILTER=y, this makes iptabes see bridged packets.

Additionally you need CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y, that allows
matching on the physical device name for bridged packets.  That way you
can filter by domain (because each domain has its own virtual bridge
port) instead of ip/mac address.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

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

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 07/28/2006 11:06:22 AM:
> 
> On 28 Jul 2006, at 15:56, Reiner Sailer wrote:
> 
> 
> You mean tag a packet when it arrives from a source domain and then use 
> that if/when it boomerangs back at you on a different virtual 
> interface?
It is a one-liner to set the input device in the skb.

> In terms of cost, an extra hypercall per packet will have measurable 
> cost, at least in CPU usage, for high-bandwidth network transfers.
> 
>   -- Keir
> 
You only make the decision once for the first packet exchanged between two 
interfaces. Afterwards you reuse this decision for this interface pair 
(local cache). You basically have the cost of looking up a decision 
locally.

Reiner

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

xense-devel-bounces@lists.xensource.com wrote on 07/28/2006 11:13:07 AM:
> > 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.
> 
> You want CONFIG_BRIDGE_NETFILTER=y, this makes iptabes see bridged 
packets.
> 
> Additionally you need CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y, that allows
> matching on the physical device name for bridged packets.  That way you
> can filter by domain (because each domain has its own virtual bridge
> port) instead of ip/mac address.
> 
> cheers,
> 
>   Gerd
Using IPtables this way sounds like a feasible compromise for the short 
term.

There are drawbacks to this short-term solution:
* dependencies on user space tools (also coordination requirements wrt 
other users of IPtables)
* performance: rules add up in IPTables when the number of interfaces 
increases
* scalability: for every interface coming up we make a number of 
hypercalls to setup the filters to the existing interfaces [O(n) for 
sHype/ACM; other non-symmetric policies might involve more overhead]

For these reasons, I suggest that we include networking in our discussions 
about the long-term security architecture and related interfaces in Xen.

If there are no other suggestions then we will proceed following the 
suggestion to use IPtables and filtering based on devices.

Reiner

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

On 28/07/06 12:30 -0400, Reiner Sailer wrote:
>   > In terms of cost, an extra hypercall per packet will have measurable
>   > cost, at least in CPU usage, for high-bandwidth network transfers.
>   >
>   >   -- Keir
>   >
>   You only make the decision once for the first packet exchanged between
>   two interfaces. Afterwards you reuse this decision for this interface
>   pair (local cache). You basically have the cost of looking up a
>   decision locally.
This is a key principle of "shype" - that they hypervisor authorizes
the channel when it to be set up. As long as the channel persists
unchaged (no additional parties, not policy modifications) there is no
need to perform further authorization. It performs a different level
of authorization than packet filtering does, and it is another layer
of depth in a multi-layer defense.

Mike


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