RFC: virtual network access control

RFC: virtual network access control

[Reiner Sailer]

[-- Attachment #1.1: Type: text/plain, Size: 1090 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1351 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: RFC: virtual network access control

[Caitlin Bestler]

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?

Re: RFC: virtual network access control

[Keir Fraser]

> 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

Re: RFC: virtual network access control

[Reiner Sailer]

[-- Attachment #1.1: Type: text/plain, Size: 1024 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1323 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RFC: virtual network access control

[Keir Fraser]

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

Re: RFC: virtual network access control

[Reiner Sailer]

[-- Attachment #1.1: Type: text/plain, Size: 2367 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2896 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RFC: virtual network access control

[Keir Fraser]

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

Re: RFC: virtual network access control

[Reiner Sailer]

[-- Attachment #1.1: Type: text/plain, Size: 734 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1012 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RFC: virtual network access control

[Mike Day]

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

Re: RFC: virtual network access control

[Harry Butterworth]

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

Re: RFC: virtual network access control

[Gerd Hoffmann]

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

Re: [Xense-devel] Re: RFC: virtual network access control

[Reiner Sailer]

[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1881 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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