On Apr 29, 2014 9:40 AM, "Christian Schaller" <cschalle(a)redhat.com>
So in response to the ongoing discussion about Firewall functionality and
desktop we had a call at the end of last week with some representatives
the desktop and firewall development teams, trying to figure out a
compromise and a way forward. I hope people can take the time to look over
the ideas we discussed and let us know if you think it is a workable
On the call was:
We had a wide ranging discussion going from what is doable in the Fedora
timeframe to what we want from a firewall solution in the long run, what
the setup is like on other operating systems, the tradeoffs between
security and usability, API and adoption, ease of sharing versus unintended
sharing and different corner cases where the different models might break
down a bit.
We all agreed on the following core principles
* We want users to be as secure as possible
* We want users to have their privacy protected as well as possible
* We want users to have a good experience using our products
* We want users to be able to use services such as DLNA, Chromecast,
Avahi and more
without having to search on Google, and more often than not
be told that the fix is to disable the firewall.
* We all agree that there is no perfect solutions on offer here. Just
range of different tradeoffs. A system with a running firewall isn't secure
nor is a system without a firewall insecure. Instead they exist on a
continium of 'more secure' and 'less secure'.
The challenges seen:
* With the current default a lot of services don't work out of the box
the firewall silently blocks them
* There doesn't seem to be any non-expensive way for the system
that a service is running and being blocked by the firwall.
* There is very limited use of the firewalld API for doing things
port unlocking and similar due to it being a predominately Fedora and RHEL
only solution currently
* Some application developers who do look into using the current API
the API hard to use
* The current NetworkManager UI to change zones is both maybe a bit
hidden away and also the Zones options listed there are not intuitive or
documented in the UI.
Plans for Fedora 21
* The Desktop team will look into creating a UI that asks you when you
connect to a
new wireless network if you consider it trusted or not. Exact
wording of the question and look of dialog etc. will need to be worked out.
This setting will be remembered for that network. If user say trusted the
zone used will be 'trusted', if not trusted then current default will be
used. Should be simple enough to not confuse users, yet improve their
security on public networks.
* Other connection types will keep the current default which sucks a
for your home ethernet, but we don't currently have a good way to identify
your ethernet connection and popping up a dialog every time you connect is
probably a worse user experience than having to google a bit.
Matthias started a prototype of this already here:
Long term plans
* Work with NetworkManager team to see if we can come up with a way to
ethernet connections in a similar manner
* Look into proposing a new DBUS API for firewalld
* We will keep talking to see if there are more granular approaches that
developed as we go forward. For many cases the trusted/untrusted
question is a bit to simple. For instance you probably trust your work
network, but that doesn't mean you want to share your beach vacation photos
on the office network.
* Look into using the zones descriptions somehow in the
Zone setting UI to make it a bit more understanable than just a list
names. FirewallD team will work on making the descriptions
Matthias filed two bugs related to this:
split off zone
configuration in subpackages
desktop mailing list
The changes to the firewall policy look good and seems to enable any
application to introspect the firewall without needing auth. IMHO, for the
time being, that's enough so long as the DEFAULT sharing apps are updated
to become aware of this and inform the user of the specific issue. For all
others it makes sense to me to create an fdo dbus api for x-desktop use.
Given the terms of the prd I don't see the necessity in doing more at this
time. Simply, sharing of the sort this would affect, doesn't seem to be a
priority given the prd language.