F21 System Wide Change: Workstation: Disable firewall

Thomas Woerner twoerner at redhat.com
Tue Apr 15 18:41:47 UTC 2014


On 04/15/2014 04:37 PM, Simo Sorce wrote:
> On Tue, 2014-04-15 at 10:28 -0400, Christian Schaller wrote:
>> ----- Original Message -----
>>> From: "Reindl Harald" <h.reindl at thelounge.net>
>>> To: devel at lists.fedoraproject.org
>>> Sent: Tuesday, April 15, 2014 11:40:20 AM
>>> Subject: Re: F21 System Wide Change: Workstation: Disable firewall
>>>
>>>
>>> Am 15.04.2014 11:32, schrieb drago01:
>>>> On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald <h.reindl at thelounge.net>
>>>> wrote:
>>
>>> allow any random application to open a unprivlieged
>>> port which is reachable from outside is dangerous
>>>
>> We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port
>> they wish to.
>>
>> There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion,
>> but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the
>> same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works.
>>
>> The thread discussing this ended up with mostly being a discussion if the firewall would be a useful way to help users from accidentally
>> oversharing on a public network. Which is important and something we want to work on, but a lot less so than security issues.
>
> There is plenty of prior art here.
>
> What you need is clearly different "zones" that the user can configure
> and associate to networks, with the default being that you trust nothing
> and everything is firewalled when you roam a new network.
>
We have that already with zones in firewalld.

> firewalld should grow a NetworkManager plugin so that configuration can
> be changed on the fly based on which network NM tells firewalld a
> specific interface is connected to.
>
We have that already: With NetworkManager and ifcfg files a 
connection/interface can be bound to a zone, it is then not in the 
default zone. NetworkManger sends out an request to firewalld to bind 
the interfaces related to a connection to the defined or the default zone.

We also have an applet (firewall-applet) to assign and change zones in 
an easy way, but because of system tray usability limitations in gnome 3 
it is not as usable as it is in other desktop environments. This is an 
system tray applet, because I can either write an gnome-shell applet, 
that is only working in gnome 3. Or I can write an applet that is 
working correctly in all other desktop environments and limited in gnome 
3 - I will not write several.

The limitations in gnome 3 are:
- Applets are not easily visible in the desktop.
- An applet is not always visible, even if the state in the applet is to 
be visible.
- Sending out notifications is prohibiting the use of left and right 
mouse button menus: While the notification is visible, a left and right 
mouse button click on the applet only shows the notification.
- After closing an notification sent out by the applet, the applet is 
made invisible in the tray with a still visible state in the applet. Not 
even a hide and show will make it visible anymore.
- Left and right mouse button menus are loose in the desktop and are not 
visibly connected to the applet, it is not visible any more after 
clicking on it.

> Applications need to be prevented from being able to arbitrarily open
> ports, that should be allowed only for a "trusted" zone. User
> intervention should be needed to mark a zone as trusted, in all other
> zones the user will have to select explicitly what applications are
> allowed.
>
> So the big work here is in the UI you need to build to present these
> configurations to the user.
>
> Until then you can present a very simplified UI that just has a big
> button/switch that turns everything from "untrusted" to "trusted", with
> the default being "untrusted" of course.
>
> Simo.
>


More information about the devel mailing list