On 06/30/2011 11:11 PM, Dan Williams wrote: > On Tue, 2011-06-28 at 19:03 +0200, Thomas Woerner wrote: >> Hello Dan, >> >> we were talking some time ago about classification of network >> connections according to their trust level in network zones. >> >> Jiri Popelka and I want to work on network zone support and also on >> making firewalld the default firewall solution for Fedora 16. For >> network zone support, we had a first look at NetworkManager to have an >> idea where and how it could be added. >> >> NetworkManager is managing the connections and interfaces and therefore >> the best place to manage the zones also in my opinion. I think an >> extention of the D-BUS interface is needed to provide information about >> the connections, the corresponding interfaces and zones, also the list >> of zones and the connections bound to a zone. Additionally the cli and >> also the UIs need some work. > The way I was looking at it, the "zone" would simply be a freeform > case-insensitive string (possibly alphanumeric characters only) in the > NM configuration (and also thus in the ifcfg files). NM wouldn't care > about the zones specifically, but would pass that through to whatever > listens to these signals. We could define some standard zone names like > "Home", "Work", "Public", etc, and we could make the UI only show/accept > those zone names. > > Whatever the firewall did with that information would be up to the > firewall; NM would simply store the information and emit it on network > events. > >> Before a connection is established a message should be sent out that the >> connection <C> with interface <I> will be placed into zone <Z>. >> Firewalld would react and add the interface <I> to the zone <Z> in the >> firewall configuration. When the <C> was disconnected a new message >> needs to be sent out to inform firewalld to remove interface <I> from >> zone <Z>. > Right; we can add a new D-Bus interface called > org.freedesktop.NetworkManager.Zones or something like that which would > namespace these signals. That's easy enough to do. We already call the > dispatcher scripts at the same places so this is pretty easy to add. > > So this would be a few small parts: > > 1) Add a new 'zone' property to the NMSettingConnection object in > libnm-util/nm-setting.c as type G_TYPE_STRING > > 2) Add a the new interface XML in introspection/ > > 3) Add a new GInterface skeleton in src/ that NMPolicy can implement, > which just defines the glib signals that would be emitted > > 4) Convert NMPolicy into a real GObject, which should be pretty trivial > since it's almost one already > > 5) Have NMPolicy implement the new GInterface > > 6) Decide whether we can just use the NMDevice object state and property > notifications of "ip-interface" to emit the signal from NMPolicy, or > whether we should create a new signal on the NMDevice object which gets > emitted at the right time, which NMPolicy then listens for and re-emits > on the new D-Bus interface after doing any munging that might be > required > > (each device has an 'interface' and 'ip-interface' property; the > 'interface' property isn't always an IP-capable kernel network interface > but is a kernel device. So for 3G modems the 'interface' property would > be eg 'ttyUSB0' and when PPP is finally brought up the 'ip-interface' > property would change to 'ppp0' which could be used with firewall rules) > > For #6, when should the signal be emitted? When NM *starts* to > configure the device even before IP addresses are acquired and assigned? > Ethernet static IP configuration is quite fast, so there could be a race > condition here if the firewall isn't fast enough applying the policy. > Do we care about that? >
Hi, I've started implementing the network zones feature [1] according to instructions in Dan's mail. I'm a glib&GObject&DBus newbie, so it took me some time and I'll be very grateful if somebody could have a look at my patches. Jirka Klimes saw them some time ago and I'd like to thank him for his notes. It's only a stub so far but it would be great if you could look at it to tell me if I'm on a good way or totally wrong so I have something to build on. So far the ConnectionAdded(iface_name, zone_name) signal from NMPolicy on org.freedesktop.NetworkManager.Zones D-BUS interface is emitted when NMDevice has been activated (or when it's ip-interface property has been changed). Also the ConnectionRemoved signal is sent when the NMDevice has been disconnected. [1] https://fedoraproject.org/wiki/Features/network-zones PS: I'm leaving for holiday tomorrow and will show up in 2 weeks. Jiri Popelka (4): New 'zone' property of the NMSettingConnection. New Zones interface Convert NMPolicy into a real GObject. Have NMPolicy implement the new NMZonesInterface. include/NetworkManager.h | 3 + introspection/Makefile.am | 3 +- introspection/all.xml | 1 + introspection/nm-zones.xml | 42 +++ libnm-glib/Makefile.am | 6 +- libnm-util/libnm-util.ver | 1 + libnm-util/nm-setting-connection.c | 52 ++++ libnm-util/nm-setting-connection.h | 2 + src/Makefile.am | 10 +- src/main.c | 2 +- src/nm-policy.c | 511 ++++++++++++++++++++++++------------ src/nm-policy.h | 21 ++- src/nm-zones-interface.c | 87 ++++++ src/nm-zones-interface.h | 51 ++++ 14 files changed, 614 insertions(+), 178 deletions(-) create mode 100644 introspection/nm-zones.xml create mode 100644 src/nm-zones-interface.c create mode 100644 src/nm-zones-interface.h -- 1.7.6 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list