F21 System Wide Change: Workstation: Disable firewall

drago01 drago01 at gmail.com
Tue Apr 15 18:17:49 UTC 2014

On Tue, Apr 15, 2014 at 6:13 PM, Andrew Lutomirski <luto at mit.edu> wrote:
> On Tue, Apr 15, 2014 at 9:04 AM, Christopher <ctubbsii at apache.org> wrote:
>> On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski <luto at mit.edu> wrote:
>>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>>> Am 15.04.2014 16:28, schrieb Christian Schaller:
>>>>> 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.
>>>> that is pretty easy - defaults have to be closed anything and the user
>>>> have to make a choice for, otherwise if there are cirtical security
>>>> updates after a release you have *exactly* the same as WinXP SP2
>>> WinXP SP2 needed a firewall because MS didn't want to close ports 139
>>> and 445 for real.  So instead they hacked it up with a firewall.  This
>>> meant that, if you had the firewall blocking those ports, you were
>>> okay, but if they were open (e.g. because you were at home), you were
>>> screwed.
>>> This is *not* a good thing.
>>> Can someone explain what threat is effectively mitigated by a firewall
>>> on a workstation machine?  Here are some bad answers:
>>>  - Being pwned via MS's notoriously insecure SMB stack?  Not actually
>>> a problem for Fedora.
>>>  - WebRTC, VOIP, etc. issues?  These use NAT traversal techniques that
>>> are specifically designed to prevent your firewall from operating as
>>> intended.
>>>  - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible
>>> for these things to be off until specifically requested?  Who actually
>>> uses a so-called "zone" UI correctly to configure them?  How about
>>> having an API where things like DLNA can simply not run until you're
>>> connected to your home network?
>>> Also, having a firewall on exposes you to a huge attack surface in
>>> iptables, and it doesn't protect against attacks targeting the
>>> kernel's IP stack.
>>> I'm all for "secure by default", but I'm not at all convinced that
>>> current desktop firewalls add any real security.
>> Ideally, users would have complete knowledge of the behavior of every
>> piece of software in their system that utilizes the network, in which
>> case, they could very easily get by without a firewall. However, that
>> is not a reasonable expectation. A firewall protects users with
>> incomplete knowledge of their software.
>> Example: user installs software X... but oops, they didn't realize it
>> was going to listen on port Y.... but that's okay, because no firewall
>> rule has been enabled to allow traffic on port Y, so the user is
>> secure.
> This sounds like a problem that should be separately fixed.  Even in
> the current state of affairs, either software X doesn't support
> firewalld, in which case we have the problem that caused this change
> request in the first place, or it does support firewalld, in which
> case it's unlikely that there will be a benefit.
>> Even worse: user installs software X, but which has no network
>> features so the user feels safe, but oops, it depends on system
>> service Y, which does open network ports, was previously disabled, but
>> is now turned on by software X. Firewalls protect against this sort of
>> incomplete user knowledge. What if software Y only enables the network
>> periodically, to perform some maintenance function? Even a pedantic
>> user checking netstat isn't necessarily going to notice network
>> services listening on ports periodically.
> Arguably this should also be fixed by cleaning up all those network services.
> With firewalls, a service, system or otherwise, can be in one of three
> states: a) listening w/ firewall open, b) listening w/ firewall
> closed, c) and not listening.
> c is secure regardless.  a is equally secure regardless.  b is IMO
> just broken.  Yes, a firewall can work around case b, at the cost of a
> lot of UI hassles and incomprehensible failures, but I think it's a
> crappy solution.
> I keep thinking that, if I had unlimited time, I'd write a totally
> different kind of firewall.  It would allow some policy (userspace
> daemon or rules loaded into the kernel) to determine when programs can
> listen on what sockets and when connections can be accepted on those
> sockets.

We could do that today by using selinux and confine all programs into
a domain that does not allow listing to any ports.
Those that have to should get labeled by a different type.

We could go as far as do that for unconfined_t as well and have the
user chcon to a "allow_ports_prog_t" or something (and have a boolean
to shut it off for everything).

But I am not sure this is less of a hassle then a firewall though.

More information about the devel mailing list