Re: [PATCH 0/4] Network Zones support

[Dan Williams <dcbw redhat com>]

On Tue, 2011-07-26 at 15:43 +0200, Jiri Popelka wrote:
> 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

So after talking with Thomas about this (and reviewing the patches) a
few weeks ago, I think we should turn the implementation around a bit.
I probably suggested that way originally but I now think instead we
should have NM tell the firewall directly what interface should get put
into what zone.  So I'd like to see a new directory in src/ called
"firewall-manager" and inside there an implementation for firewalld that
tracks whether firewalld is on the bus or not (see supplicant-manager or
modem-manager for examples).  Then in nm-device.c at stage5
(ip-config-commit) before we actually apply the IP configuration to the
interface, we should send the IP interface name and zone to firewalld
and wait for a D-Bus reply (asynchronously of course).  Then after we
get the reply (or if the firewall isn't running) we proceed with
applying the IP configuration to the interface.

My approach to this would be to modify
nm_device_activate_schedule_stage5_ip_config_commit() so that it always
calls the firewall code (sending a callback function as an argument) to
send the interface/zone to firewalld, but if the firewall isn't running,
the firewall manager bits just call the callback.  We need to track the
D-Bus call so that if we're told to deactivate the device during the
D-Bus call to firewalld we can clean it up.  What I'd do here is just
have something like:

gpointer fw_manager_add_to_zone (const char *ip_iface, const char *zone,
FwAddToZoneFunc callback, gpointer callback_data);

where the function would just return the DBusGProxyCall* pointer.  This
pointer would get stored in a new private member of NMDevicePrivate.
The pointer might later be passed to a function called:

void fw_manager_cancel_add (gpointer fw_call);

where that function would simply call dbus_g_proxy_cancel_call().  The
firewall-manager bits would obviously be a singleton and create a single
DBusGProxy at initialization which it would then use for all subsequent
calls to firewalld.

NMDevice's deactivate() code would call fw_manager_cancel_add() to make
sure that if the device was deactivated during a call to firewalld that
everything was cleaned up.

Then in the firewall-manager code when the D-Bus reply comes back, the
code would call the callback passed into add_to_zone().  You'll probably
need to allocate a small structure in add_to_zone() to hold the callback
function and user_data pointer, but this can be easily freed with
dbus_g_proxy_begin_call_with_timeout().  I dont' think we need to track
these structures in the firewall-manager itself because they'll always
be freed when the device calls fw_manager_cancel_add() even if the dbus
reply callback doesn't get called for whatever reason.

If that sounds understandable let me know, otherwise I could elaborate.
Or if you've got a cleaner way to do it, don't hesitate to suggest...

Thanks!
Dan