This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: virtual network access control
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Fri, 28 Jul 2006 10:56:07 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx, Bryan D Payne <bdpayne@xxxxxxxxxx>
Delivery-date: Fri, 28 Jul 2006 07:56:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <7f894abf693cfd1776ca9122098537cc@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 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.

Xen-devel mailing list