Re: [PATCH 0/4] Network Zones support

[Dan Williams <dcbw redhat com>]

On Fri, 2011-07-29 at 17:00 -0500, Dan Williams wrote:
> On Wed, 2011-07-27 at 16:31 +0200, Thomas Woerner wrote:
> > Hello Ludwig,
> > 
> > On 07/27/2011 01:45 PM, Ludwig Nussel wrote:
> > > 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:
> > >>>> we were talking some time ago about classification of network
> > >>>> connections according to their trust level in network zones.
> > >
> > > Nice, that's something SuSEfirewall2 would benefit from too :-)
> > >
> > >>> 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?
> > >
> > > Ideally NM should signal the firewall as soon as the interface is
> > > available (but not up yet) and wait until the firewall is done.
> > NM will send out a signal before a connection will be established. It 
> > might not be possible to wait for the firewall to finish configuration 
> > before getting the interface up, but this still needs to be verified. We 
> > will try to make this possible.
> > 
> > > The rules need to be established before the link is ready as e.g. IPv6
> > > autoconfig likely completes before IPv4 DHCP ie even before NM would
> > > consider the connection fully up. A hostile network could even delay
> > > DHCP to extend the time window. If the interface previously was in a
> > > trusted zone the machine might be wide open.
> > If NM is taking down a connection, then it will send a signal that the 
> > connection and the matching interface should be removed from the zone 
> > (and should not make it into the trusted zone in my opinion). Therefore 
> > an interface should not belong to a zone before a connection with that 
> > interface will be established.
> > 
> > > OTOH the risk could be mitigated if the firewall resets the interface
> > > rules to a restrictive set on connection termination.
> > >
> > firewalld will use the untrusted zone here. But it would also be 
> > possible to use another zone as the default zone - even depending on the 
> > connection type.
> > 
> > > Btw, how does NM or rather nm-applet know what zone names are valid?
> > > I suppose there needs to be dbus service that returns a list of zones
> > > (with translations, descriptions, icons, ...), right?
> > >
> > Yes, it might be good to get the zone list and zone related information 
> > from the service dealing with the firewall. But this is not fully done yet.
> > 
> > We thought of default zones to start with: (fully) trusted, home, work, 
> > public, (fully) untrusted.
> 
> NM shouldn't really care what the zones are; they should simply be
> passed through from the configuration to the firewall.  What would want
> to know about different zones would be the UI that handles setting which
> zone the connection is in, and that UI would get the zones either from a
> predefined list, or from some service.
> 
> The *configuration* data (ie, the bits in the NMSetting for 'home',
> 'trusted', etc) should not be localized.  But the UI should be smart
> enough to look up the localized name for those.  Think of these strings
> like an enum or define or something instead of a localizable string.  If
> we localize these strings then it's impossible to automatically
> determine anything about them.

One other note; if we want to block a bit on the firewall setting things
up, we want to slot this in during "stage3" (ip config start) before
"stage4" (ip config get) gets called, because only them do we know the
actual interface name to send to the firewall.  For things like PPP,
PPPoE, Bluetooth DUN, etc, we don't know the actual IP interface name
until halfway through the connection setup process.  But at that point
it should be safe to block for a short time for the firewall to do its
work.

One other thought though, how do we handle DHCP with the firewall?  NM
tries to do DHCP (which might need holes punched and stuff) during
"stage3", which in  my proposal above is before the firewall would be
told the interface name.  Is that a problem?

Dan