Desktop and FirewallD

[Christian Schaller]

Hi everyone,
So in response to the ongoing discussion about Firewall functionality and the desktop we
had a call at the end of last week with some representatives from both
the desktop and firewall development teams, trying to figure out a good 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 solution.

On the call was:
Thomas Woerner
Matthias Clasen
Bastien Nocera
Daniel Kopecek
Jiri Popelka
Peter Vrabec

We had a wide ranging discussion going from what is doable in the Fedora 21 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 a 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 because the
firewall silently blocks them
* There doesn't seem to be any non-expensive way for the system to detect that a
service is running and being blocked by the firwall.
* There is very limited use of the firewalld API for doing things like 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 find 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 bit 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:
https://bugzilla.gnome.org/show_bug.cgi?id=727580

Long term plans
* Work with NetworkManager team to see if we can come up with a way to identify 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 can be 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 NetworkManager Zone setting UI to
make it a bit more understanable than just a list of names. FirewallD team will work on
making the descriptions internationalizable.

Matthias filed two bugs related to this:

https://bugzilla.redhat.com/show_bug.cgi?id=1091067 split off zone
configuration in subpackages
https://bugzilla.redhat.com/show_bug.cgi?id=1091068 overprotected api

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/29/2014 09:40 AM, Christian Schaller wrote:

>  * Other connection types will keep the current default which sucks
>  a bit 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.
>   
One thing we might attempt is to do a UPnP discovery on the ethernet
network. Most home routers nowadays have UPnP support and we could use
that as a way to determine that you were on a home network. It
wouldn't work in all cases, but probably would improve the situation
for the majority of users.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlNfr3cACgkQeiVVYja6o6NXfgCgqJgCgey7ifv9dI3Vn49BFDP5
> PNIAniXOpJr6mblKYlNTbvj/Wo8PZ2dx
> =5Tqh
> -----END PGP SIGNATURE-----

[Elad Alfassa]

On Tue, Apr 29, 2014 at 4:56 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt;wrote:

>  One thing we might attempt is to do a UPnP discovery on the ethernet
>  network. Most home routers nowadays have UPnP support and we could use
>  that as a way to determine that you were on a home network. It
>  wouldn't work in all cases, but probably would improve the situation
>  for the majority of users.
>  
Not really a good idea, coffee shops might have UPnP too, or an attack
could set up a small UPnP server to respond to such queries.
We can use UPnP to discover network "name" (the name of the UPnP IGD
Device) on wired connections, tho.

-- 
-Elad Alfassa.

[Bruno Wolff III]

On Tue, Apr 29, 2014 at 09:56:07 -0400,
   Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> One thing we might attempt is to do a UPnP discovery on the ethernet
> network. Most home routers nowadays have UPnP support and we could use
> that as a way to determine that you were on a home network. It
> wouldn't work in all cases, but probably would improve the situation
> for the majority of users. 
How about tracking the mac address of the router?

[Florian Weimer]

On 04/29/2014 08:58 PM, Bruno Wolff III wrote:

> > One thing we might attempt is to do a UPnP discovery on the
> ethernet
> > network. Most home routers nowadays have UPnP support and we could use
> > that as a way to determine that you were on a home network. It
> > wouldn't work in all cases, but probably would improve the situation
> > for the majority of users.
>
>  How about tracking the mac address of the router? 
I think there are some DHCP bypasses out there (ping the default 
gateway) that would leak the MAC addresses.  Do we never want to 
implement those?  They could speed up waking from suspend.

I'm also not sure that clearing the ARP table is properly synchronized 
with suspend (considering that locking the screen still is not, at least 
in some dual-monitor setups with F20).

-- 
Florian Weimer / Red Hat Product Security Team

[Liam]

On Apr 29, 2014 9:40 AM, "Christian Schaller" <cschalle(a)redhat.com&gt;
wrote:
>  Hi everyone,
>  So in response to the ongoing discussion about Firewall functionality and 
the
desktop we had a call at the end of last week with some representatives
from both
>  the desktop and firewall development teams, trying to figure out a
> good 
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
solution.
>  On the call was:
>  Thomas Woerner
>  Matthias Clasen
>  Bastien Nocera
>  Daniel Kopecek
>  Jiri Popelka
>  Peter Vrabec
>
>  We had a wide ranging discussion going from what is doable in the Fedora 
21
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
> a 
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 
because
the firewall silently blocks them
>  * There doesn't seem to be any non-expensive way for the system
> to detect 
that a service is running and being blocked by the firwall.
>  * There is very limited use of the firewalld API for doing things
> like 
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
> find 
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
> bit 
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:
>  https://bugzilla.gnome.org/show_bug.cgi?id=727580
>
>  Long term plans
>  * Work with NetworkManager team to see if we can come up with a way to 
identify
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 
can be
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
> NetworkManager 
Zone setting UI to make it a bit more understanable than just a list
of
names. FirewallD team will work on making the descriptions
internationalizable.
>  Matthias filed two bugs related to this:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1091067 split off zone
>  configuration in subpackages
>  https://bugzilla.redhat.com/show_bug.cgi?id=1091068 overprotected api
>  --
>  desktop mailing list
>  desktop(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/desktops 
Hi Christian,
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.

Best/Liam

[Bastien Nocera]

----- Original Message -----
>  Hi everyone, 
<snip>
>  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 bit 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:
>  https://bugzilla.gnome.org/show_bug.cgi?id=727580 
The plan has changed slightly after discussions with designers (Allan in particular)
and firewalld hackers (Miloslav Trmac and Thomas Woerner).

There were two main uses to the firewall:
- Security, this is to avoid particular services from ever being seen on the network
  This also accounts for packaging errors which mean that unwanted services are
  enabled when the package is installed, and listening on the network when they
shouldn't
  be, as noticed recently: https://fedorahosted.org/fesco/ticket/1310
- Privacy, avoid unwanted data about the user, or their setup from being broadcast on the
  local network. That means my user name, my real name (!), the version of my OS, etc.

I reviewed the default network services available on a stock Fedora Workstation
installation[1], and we came up with the following plan.

1) Work with QE to setup a way to avoid security regressions, as the rpcbind one,
   mentioned above. This will mean adding tests at the distro level. Hopefully Tim Flink,
   CC:ed, can help me with creating those tests
2) Create a new firewalld zone for use by Workstation. This would block all system
   services (port < 1024) except a few whitelisted ones (see Google spreadsheet
below),
   so as to mitigate #1
3) Add Network awareness to GNOME's controls of system-wide sharing. When
disconnecting
   from the network, or connecting to a new unknown network, we would ensure that all
   sharing (we can control) is disabled. Each of the possible shared items would be
   controlled independently for each network. This means that your music would
   automatically be shared when at home, but disabled when at the coffee shop.
   We'll also have a way for users to disable sharing that was previously enabled,
without
   that network being the current one. Subject to changes, here are some mockups:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/...
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/...
   In the future this could be further controlled through application sandboxing.

Some things that are currently outside of scope, and will need to be documented:
- NFS client or server support. NFS 101 tells you to check the firewall config,
  you'll still need to do that.
- Support for network printers enumeration when mDNS is disallowed on the network
  (this opens up UDP port 631 on the local machine)

>  Long term plans
>  * Work with NetworkManager team to see if we can come up with a way to
>  identify ethernet connections in a similar manner 
This would still be useful:
https://bugzilla.gnome.org/show_bug.cgi?id=723084

Cheers

[1]:
https://docs.google.com/spreadsheets/d/103SAK-7ch5wpGiCP3KF9CYlIhLQFTy9SS...