F21 System Wide Change: Workstation: Disable firewall

Josh Boyer jwboyer at fedoraproject.org
Wed Apr 16 13:03:48 UTC 2014

On Wed, Apr 16, 2014 at 8:59 AM, Thomas Woerner <twoerner at redhat.com> wrote:
> On 04/16/2014 02:28 PM, Josh Boyer wrote:
>> On Wed, Apr 16, 2014 at 7:11 AM, Ian Malone <ibmalone at gmail.com> wrote:
>>> On 16 April 2014 00:11, William Brown <william at firstyear.id.au> wrote:
>>>> On Tue, 2014-04-15 at 13:49 -0700, Matthias Clasen wrote:
>>>>> I don't think we want a 'firewall' UI anyway; the firewall is not
>>>>> something most users can or should understand and make decisions of.
>>>> Never take decisions away from users.
>>>> The OSX style firewall works well when enabled. It blocks all by
>>>> default, then when an application wants a listening port, the user is
>>>> prompted to allow or deny it. I think this is a good model.
>>> "Users can't understand a firewall, let's just turn it off" (I realise
>>> that's not your position, it's the one that seems to be coming up in
>>> this thread.)
>>> Anyone else astounded this discussion is actually taking place?
>> I'm astounded that everyone on all sides is showing a complete
>> inability to think outside their own box in this thread.  Beyond that,
>> nothing else surprises me.
>> For a quick summary:
>> 1) With a firewall enabled, network services don't work without manual
>> intervention.
>> 2) With firewalld active, any privileged application can open a port
>> in the firewall (and most will be privileged because they will be
>> packaged that way.)
> We are using auth_admin_keep. So the user needs to enter the admin password
> for all applications that are not running as root to modify the firewall.
> But an application (and the user) is able to get information about most
> parts without the admin password.
>> 3) With no firewall enabled and no network services started, there is
>> no security issue because there are no open ports.
> Mostly all desktop sharing tools are using dynamic ports and some or all of
> them are started as soon as you are logging in.

That is true.  Those would be "network services" though.  If they
aren't started, there are no open ports.  If they are started, there
are.  I was being very literal.

>> 4) With no firewall but active network services, you have open ports
>> just as you would in the firewalld or manual intervention firewall
>> case
> No, see above. You need to authenticate them to be able to modify the
> firewall.

For all intents and purposes, the end state winds up being the same.
As Dan Walsh said in another email in this thread, asking users
security questions results in them saying "yes" or authenticating in
the vast majority of the cases.

>> 5) Which ports can safely be opened is completely irrelevant to the
>> presence of a firewall or not.  It is entirely dependent upon the
>> trust of the network the machine is connected to.  On unsafe networks,
>> you have one of two options: a) turn off those network services, b)
>> use a firewall to block the ports those network services need (which
>> is a strange form of a).
>> If those facts hold true, and I think they do, then I am not surprised
>> at all that there's no consensus here.  It isn't as clear cut as
>> everyone seems to want it to be.
>> The zones approach seems fairly reasonable to me.  That in and of
>> itself doesn't require a firewall though.  "Zones" could be
>> implemented by simply turning off the network services completely,
>> which would then close the open ports.  However, using a firewall to
>> implement zones does allow for protection against unknown/unwanted
>> network services running.
>> A reduced set of zones firewall rules and proper integration in
>> whatever implementation is chosen would seem to be the middle ground
>> here.  I like the middle ground.  Maybe we could shoot for that?
>> Otherwise, I won't be astounded at all when FESCo rejects the current
>> Change and some users still turn off the firewall as one of the first
>> things they do because things don't work.
> There has been a plan about this before. It only need to be reworked and
> implemented.

Well, sounds like a great first step!


More information about the devel mailing list