[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [patch 5/5] xen: net features

  • To: "Jody Belka" <lists-xen@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Tue, 1 Feb 2005 00:45:28 -0000
  • Delivery-date: Tue, 01 Feb 2005 00:49:35 +0000
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
  • Thread-index: AcUH9NpW3lEm7u6eTB6ELCWyvp7bngAAROMg
  • Thread-topic: [Xen-devel] [patch 5/5] xen: net features

> I was thinking of something along the lines of adding a tiny 
> bit of code
> to remove the CAP_SYS_MODULE and CAP_SYS_RAWIO capabilities 
> from the global
> set of allowed cap's when using the readonly option. With 
> that in place you're
> down to requiring a kernel-hole to get around it.

I'd prefer to just enforce it in the backend, rather than have something
that could potentially be subverted. 

> > > > > (2) the addition of some xen-specific sysfs attributes
> > > > > on front/back vifs, 
> > > > 
> > > > What attributes?
> > > 
> > > Backend:
> > > - xen/fe.domain: frontend domain name
> > > - xen/fe.initial_address: initial frontend interface mac address
> > > - xen/fe.mac_mode: mac mode of the frontend interface (r/w)
> > > - xen/be.mac_mode: mac mode of the backend interface (r/w)
> > I can see some point having the be enforce the MAC, and possibly in
> > having the enforcement address being configurable via 
> sysfs. I'm not a
> > big fan of this section of the patch, though.
> The entire idea of it or just the current attributes?

I can see the point of having some controls on the backend:

xen/fe.domain_name: frontend domain name (read only, for reference)
xen/fe.mac:         all transmitted packets must have this MAC

Having said that, since most people want to enforce a given src IP
address and hence have to use iptables anyway, its not buying us a huge
amount. Ebtables can be used to have the same effect very easily.

Having the fe domain name stored in the kernel is somewhat distasteful
as its purely for user space's benefit and we're likely to get into
"should it be the name or uniqueid?" issues.


This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.