"Workstation" Product defaults to wide-open firewall

Gerd Hoffmann kraxel at redhat.com
Tue Dec 9 15:59:15 UTC 2014


> > Side Note: For the latter we need to cleanup the zones though.  There
> >            are *way* to many to choose from, and the names suck big
> >            time.  WTF is a "Fedora$product" zone?  And wasn't that
> >            discussed before on this list?  Why do we *still* have this
> >            mess?
> This isn't a side note, IMO. It was one of the major reasons why we chose
> not to expose users to the concept of zones.

IMO it would have been better to fix the zones instead.  The concept is
good, we just have too many with of them, with bad names.  We basically
need one for public networks (Hotspots etc) and one for Home/Work, with
good names and sensible defaults.  Maybe also "allow all" and "block all
(including outgoing traffic)" zones, but thats it.

The "internal", "external", "dmz", ... zones sound like they are
intended for machines running as router.  They should either be moved to
a subpackage (so they are not installed by default), or dropped
altogether.  Or maybe tagged as "expert" zones, so they are hidden by
default in the UI.

> In addition to the names being
> obscure in firewalld (there's a bug filed about that), they also are obscure
> in Windows.

> What configuration difference is there between home and work, and how do you
> explain them without going deeper into technical details?

Microsoft figured this too, so as I've already mentioned this home/work
is gone now (win8 fully updated).

> > IMO there is simply no way around asking the user.
> Instead of asking the user, we're getting the user to tell us they want to share
> things. This avoids unnecessary nagging.

Problem is this doesn't work for apps outside the gnome universe.  For
example I can ask libvirt to make the qemu vnc server listen on any
interface, if I want access the guest screen from another machine.

With firewall zones I can easily get the behavior I want: guest screen
is reachable in my home network, but not in the coffee shop.

> > Make sharing stuff
> > easy (so you can watch your dnla-exported photo/video collection at your
> > smart tv) is a reasonable request.  But enabling that by allowing
> > everybody fetch your private photo collection via dnla while you are
> > surfing @ starbucks is a non-starter.
> This isn't what was implemented. DLNA share will be turned off by default on
> new networks. In fact, we won't allow any unencrypted services to run when
> on unencrypted Wi-Fi.

The gnome dnla server might do this.  There are other dnla servers, and
other apps opening network ports, which don't follow this policy.


More information about the devel mailing list