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

[Reiner Sailer <sailer@xxxxxxxxxx>]

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.

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