Re: [PATCH 0/4] Network Zones support
- From: Dan Williams <dcbw redhat com>
- To: Thomas Woerner <twoerner redhat com>
- Cc: Ludwig Nussel <ludwig nussel suse de>, networkmanager-list gnome org
- Subject: Re: [PATCH 0/4] Network Zones support
- Date: Fri, 29 Jul 2011 17:00:47 -0500
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.
] [Thread Prev