RFC: virtual network access control

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: virtual network access control

Reiner Sailer

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
_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] 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


_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

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

Reiner Sailer

Keir Fraser <[hidden email]> 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
_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] 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


_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

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

Reiner Sailer

Keir Fraser <[hidden email]> 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
_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xen-devel] 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


_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

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

Gerd Hoffmann
In reply to this post by Reiner Sailer
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 <[hidden email]>
http://www.suse.de/~kraxel/julika-dora.jpeg

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

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

Reiner Sailer
In reply to this post by Keir Fraser

Keir Fraser <[hidden email]> 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
_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

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

Reiner Sailer
In reply to this post by Gerd Hoffmann

[hidden email] 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
_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel