On Tue, Apr 15, 2014 at 6:13 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > On Tue, Apr 15, 2014 at 9:04 AM, Christopher <ctubbsii@xxxxxxxxxx> wrote: >> On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: >>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
