Fedora 21 and its Workstation firewall
The Fedora 21 Workstation release came with a "feature" that was unexpected by some in the Fedora community. To those folks, the fact that the default firewall rules allow programs to listen and receive traffic on all non-privileged (> 1024) port numbers is a huge security hole, but to others it is precisely what was needed to support certain desktop use cases. Which reaction seems to depend on the person's expectations for the firewall—or for Fedora desktops.
Kevin Kofler raised the issue in early December. He noticed that the Workstation product configured the firewall to allow both UDP and TCP connections to ports 1025-65535. As is usual for Kofler, he didn't mince any words:
There had been a prior discussion on this list where they wanted to disable the firewall entirely. We told them that that's a horrible idea (which it is, of course!). But the result is that they implemented this "solution" which is almost entirely as bad, and which additionally gives users a false sense of security, because a "firewall" is "enabled" (for a very twisted definition of "enabled").
This configuration only affects one of the three products (i.e. the Workstation product) that the project delivered in the Fedora 21 release. That was the first release since the adoption of the product-focused Fedora.next strategy. The other two products have different firewall requirements, so the Server product has a much more locked-down firewall, while the Cloud product has no firewall at all since it is envisioned to be deployed in situations where network filtering is handled by another layer.
The reaction to Kofler's posting was mixed. Paul Howarth pointed out that the Release Notes did mention that the firewall is "developer oriented":
Ports numbered under 1024, with the exceptions of sshd and clients for samba and DHCPv6, are blocked to prevent access to system services.
The notes go on to describe where to get more information along
with a recommendation for the firewall-config package if a
GUI tool to manage the configuration is needed. But, as Ian Malone noted, developers are likely already able to
configure their firewalls if they need to, so the developer-oriented
firewall really boils down to one that allows connectivity for
consumer-oriented devices. That makes this change "feel rather like
a fedora-no-longer-has-your-back moment
", he said. Harald Reindl agreed, saying that "people switched to Linux systems to go in the 'secure by default'
direction
" but that, sadly, those times are gone.
Others, including some of the project members responsible for the change, disagreed. For some time now, Bastien Nocera has searched for some way to do media and file sharing without users having to fiddle with the firewall configuration. After some discussions in mid-2014, he posted a plan to the Fedora Desktop mailing list (which is where Workstation changes are usually discussed) in June. The implementation of that plan have just now appeared in the F21 Workstation release.
It should be noted that no services on high ports are started by the default installation of F21 Workstation. If users choose to enable sharing of media or files (using WebDAV or Rygel, for example), servers using high ports may be started and the firewall will not get in their way. Based on Nocera's posts, it seems clear that sharing between workstations was the main target of the feature.
In the past, the firewall configuration problem might have been handled by querying the user, or by having them set a particular firewall zone. According to Nocera and others, though, asking users security questions is a bad user interface choice. Instead, if the user chooses to share data (using the GNOME sharing dialog described in Nocera's blog post, for example), the network they are currently on is determined "safe" for sharing. New networks, or those that use unsecured WiFi, are considered to be unsafe, so sharing is disabled in those cases.
While several in the thread said—often rather caustically—that developers should be able to reconfigure the firewall if needed, Richard Hughes disagreed. It is a matter of who is being targeted by the Workstation product; the working group made a particular choice there. In fact, he said, the changes will make his system more secure:
I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less.
For the most part, the opponents of the change did not find the need for
various sharing protocols to be able to open a variety of high ports to be
at all compelling. But, as Michael Catanzaro pointed out, that is a use case that the
Workstation working group has decided to support. "So your challenge is to find
an alternative default that
supports it: then we'll have more to talk about.
"
Trying to pass the feature off as one for developers, though, as the release notes do, when the proponents keep harping on the sharing use case, as Catanzaro, Nocera, Hughes, and others do, also bothers some. As Brian Wheeler put it:
This is the problem I've got with this feature. It has nothing to do with developers and everything to do with making a gnome feature work without having to click a "I really want to open everything because I'm on a trusted network" box.
There are ways for those who want more security to get it, of course. Stephen Gallagher posted multiple options depending on the level of security required (all the way up to "Reindl-level"). He also pointed out that buried inside the Network Manager "Identity" settings, there is a way to associate a particular zone with each connection. But, opponents of the change point out that the default could have been left as it was and those that needed or wanted the firewall to allow more ports could, instead, switch their zone.
In addition, it seems there is a difference of opinion about the course of the discussion between the Fedora firewall developers and proponents of loosening the firewall restrictions. Nocera touted the agreement of the firewall developers several times in the thread, but Thomas Woerner, one of those developers, had a rather different view. They went back and forth a few times, but Nocera was adamant that the firewall team had signed off on the changes—and that the changes did not really change the default security of the Workstation product in any case.
This is, of course, just the kind of dispute that will not result in any kind of consensus emerging. So, Kofler duly referred the matter to the Fedora Engineering Steering Committee (FESCo) for resolution. He would like to see an immediate security update to the Workstation product that closes all the high ports. He also claimed that the working group essentially ignored an earlier FESCo decision that disallowed disabling the firewall for the Workstation product and simply worked around it by gutting the firewall's protections.
FESCo took up the issue at its December 17 meeting, though it deferred a decision until its January 7 meeting since several of the principals (Nocera, Woerner, and firewall developer Miloslav Trmač) could not attend. Fedora project leader Matthew Miller did note, however, that he was unhappy with the tone of the FESCo ticket that, he said, implied some malfeasance on the part of the Workstation working group. From the discussion, it would seem unlikely that FESCo will require that the firewall configuration change.
The biggest problem here seems to be one of expectations. Some expect their media sharing to "just work" with Fedora Workstation, while others require a system that is largely locked-down by default. The former group generally plans to operate their systems in friendly environments, perhaps, while the other group is leery of that "friendly" designation. It is pretty hard to satisfy both with one set of defaults. Perhaps, as Miller suggested in the thread, those looking for a more locked-down Workstation should turn to the Fedora Netizen spin.
| Index entries for this article | |
|---|---|
| Security | Distribution security |
| Security | Tools/Firewall |
Posted Dec 18, 2014 2:18 UTC (Thu)
by dashesy (guest, #74652)
[Link] (1 responses)
Posted Dec 19, 2014 5:16 UTC (Fri)
by mcatanzaro (subscriber, #93033)
[Link]
Posted Dec 18, 2014 2:19 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (7 responses)
In Fedora's defense, their thinking is that "workstation" implies a desktop or laptop computer in a corporate or small office environment; it would seem reasonable to assume the computer(s) had firewall protection provided by another device (NAT router, other dedicated firewall computer, etc.). Or, if this "workstation" was provisioned to be the (physical) firewall, then the sysadmin could/would reconfigure the (software) firewall in a more secure manner. If the user/sysadmin deploying Fedora 21 did not take either of the steps above, then that organization has bigger issues than having a "Swiss cheese" firewall. Key words above are "could" and "would"... Just my $0.02.
Posted Dec 18, 2014 19:03 UTC (Thu)
by meyert (subscriber, #32097)
[Link] (5 responses)
Posted Dec 19, 2014 0:07 UTC (Fri)
by sjj (guest, #2020)
[Link] (4 responses)
- have they actually worked in small/midsize companies and observed security practices? Hint: not great.
Posted Dec 19, 2014 5:15 UTC (Fri)
by mcatanzaro (subscriber, #93033)
[Link] (3 responses)
Indeed, but we don't believe the looser firewall is significantly less secure.
- do they ever use their laptop in a coffee shop?
This is why sharing is only enabled on a per-network basis, as mentioned in the article.
- are there no students using Fedora?
Hi, me. Last year, I wasted an hour trying to figure out why my network program worked on other distros but not Fedora. Eventually I realized that the firewall was to blame, but it was a frustrating experience and I was getting ready to give up on Fedora by the end of it. P.S. I'm a Fedora developer, so imagine how well NORMAL students would react to this.
- why should I lower my shields and be vulnerable to my cow-orkers' machines?
Well, as mentioned in the article, no services are listening on these ports by default, so it makes no difference. If you install such a service AND manually enable it (Fedora requires almost all network services to be disabled by default when installed) then you presumably want it to work, no?
Posted Dec 23, 2014 3:36 UTC (Tue)
by sjj (guest, #2020)
[Link] (2 responses)
Seriously, a big change in default security policy, and no mention in the release notes? I searched for "fire" - did I miss it?
Posted Dec 23, 2014 4:21 UTC (Tue)
by mchapman (subscriber, #66589)
[Link] (1 responses)
It is mentioned at http://docs.fedoraproject.org/en-US/Fedora/21/html/Releas... .
Note also that if you have previously associated a particular firewall zone with your network connections, then those settings will be carried across the upgrade. The new zones are only used for connections that have not had a specific zone set.
In my opinion there is a bug here. The firewalld-config-workstation package (and the corresponding packages for the other Fedora products) will not replace your firewalld.conf, and hence this default zone, upon package upgrades... but the firewalld-config-workstation package is *new*, which means it's not being treated as an upgrade.
Posted Dec 23, 2014 20:26 UTC (Tue)
by sjj (guest, #2020)
[Link]
Posted Dec 19, 2014 4:59 UTC (Fri)
by mcatanzaro (subscriber, #93033)
[Link]
The looser firewall config is actually specifically intended for home users. I presume media sharing is not very common in corporate environments.
Posted Dec 18, 2014 2:34 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
All the ports must be treated similarly, the entirely artificial distinction only gets in the way and causes actual security issues while solving nothing at all.
For example, MySQL runs at port 3306, PostgreSQL runs on port 8354 and so on. Ejabberd, on the other hand, must run as root because it needs to listen to so called 'privileged' ports. And I challenge you to fix it without patching away the privileged port checking.
Posted Dec 18, 2014 6:20 UTC (Thu)
by foom (subscriber, #14868)
[Link] (15 responses)
Doesn't xmpp usually use port 5222? Anyways, yes, you *can* bind those ports, without root, without patching the kernel. You just need the server to have the cap_net_bind_service capability.
See e.g.
http://stackoverflow.com/a/7701793
Alternatively you can use authbind (which, these days, years later, does actually support IPv6)
Posted Dec 18, 2014 14:08 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
> Anyways, yes, you *can* bind those ports, without root, without patching the kernel. You just need the server to have the cap_net_bind_service capability.
> See e.g.
> Alternatively you can use authbind (which, these days, years later, does actually support IPv6)
And all of that for something that does not add any real security.
Posted Dec 18, 2014 19:05 UTC (Thu)
by meyert (subscriber, #32097)
[Link] (5 responses)
Posted Dec 18, 2014 19:14 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Dec 18, 2014 19:33 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (3 responses)
Or, in a more Unix style (and working for any language, and with a smaller part running as root): have the root part do nothing more than opening the listening socket and giving the socket to the main program via file descriptor passing.
Posted Dec 18, 2014 19:36 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> Or, in a more Unix style (and working for any language, and with a smaller part running as root): have the root part do nothing more than opening the listening socket and giving the socket to the main program via file descriptor passing.
Posted Dec 18, 2014 19:39 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (1 responses)
Sorry for being unclear. I meant a small helper Unix program, running as root, which receives a request from the main program "open me port 1234" through the Unix domain socket, opens a listening socket on the requested port, sends the socket's fd to the main program via file descriptor passing, and closes its copy of the fd.
Posted Dec 18, 2014 19:42 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
It still is a crap solution - lots of complexity and potential for failures for no real reason at all. What's even more infuriating is that the whole capability mechanism in Linux seems to be braindead, because even simple obvious actions are clearly impossible.
Posted Dec 19, 2014 2:35 UTC (Fri)
by foom (subscriber, #14868)
[Link] (1 responses)
Haha, did not see that. :)
You can use filesystem caps on the ejabberd binary now at least, can't you?
Posted Dec 19, 2014 2:54 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
However, it's a very brittle:
Posted Dec 25, 2014 11:32 UTC (Thu)
by job (guest, #670)
[Link] (5 responses)
The user could then multiplex whatever applications he/she wanted to publish (using URL routing and/or SNI) using the standard web server component provided by the system?
At least this is how I would expect things to work.
Posted Dec 25, 2014 19:03 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
And there might be additional reasons to want ejabberd to listen directly on ports 80 and 443. For example, I want only ejabberd on that machine without having to exposure a huge daemon written in C to the network.
Posted Dec 26, 2014 4:25 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 26, 2014 9:28 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (2 responses)
(It exposes a huge kernel written in C to the network, but it's already exposed anyway, so...)
Posted Dec 26, 2014 18:37 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Dec 26, 2014 21:37 UTC (Fri)
by foom (subscriber, #14868)
[Link]
Posted Dec 18, 2014 7:10 UTC (Thu)
by brouhaha (subscriber, #1698)
[Link] (5 responses)
Posted Dec 19, 2014 5:40 UTC (Fri)
by mcatanzaro (subscriber, #93033)
[Link] (4 responses)
Posted Dec 23, 2014 6:48 UTC (Tue)
by brouhaha (subscriber, #1698)
[Link] (3 responses)
I haven't kept track, so I'll concede that it may not be as common as exploits against services on well-known ports, but it definitely happens.
Posted Dec 23, 2014 14:00 UTC (Tue)
by mcatanzaro (subscriber, #93033)
[Link] (2 responses)
If the socket was not opened by a service that you did not want running in the first place, then it must have been opened by a malicious service that had already compromised your system, no? At this point, I think you're already hosed: let's not pretend that locking down the high ports will actually help prevent data exfiltration....
Posted Dec 23, 2014 17:23 UTC (Tue)
by raven667 (subscriber, #5198)
[Link]
Posted Dec 25, 2014 11:38 UTC (Thu)
by job (guest, #670)
[Link]
Anyway, the only unwanted services we had trouble with was those that the users themselves had installed manually. (Mainly voip and file sharing software.)
Any inbound packet filtering would only have caused trouble, because it would have provided people with a false sense of security (as in "I don't need to use a strong password because only my lab friends will reach this").
Posted Dec 18, 2014 8:37 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Dec 18, 2014 16:07 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
Posted Dec 18, 2014 13:31 UTC (Thu)
by andreasn1 (guest, #88420)
[Link] (7 responses)
Maybe with these changes in Fedora 21 I'll keep it running for a while longer on a fresh system, but we'll see.
Posted Dec 18, 2014 13:51 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
You are far from the only one.
Posted Dec 18, 2014 15:20 UTC (Thu)
by nedrichards (subscriber, #23295)
[Link]
Posted Dec 19, 2014 0:00 UTC (Fri)
by sjj (guest, #2020)
[Link] (4 responses)
Why?
Posted Dec 19, 2014 2:57 UTC (Fri)
by ebassi (subscriber, #54855)
[Link] (2 responses)
can't say for Andreas, but for me it actively prevents me from using my local network. I have UPnP/DLNA devices, as well as devices (laptops, tablets) that use mDNS. I want to watch movies on my NAS, or print pages on my networked printer, and I don't want to become a sysadmin for my home network. my laptop rarely leaves a trusted network (home or work), and if I'm not on a trusted network (e.g. coffee shop) I usually don't run any service at all. I would be better served by a system that lets me declare that a network is trusted or not than a UI that asks me every time I launch an application, or somebody tries to poke my machine — and this kind of UI would also train me to click "Yes" every time, which is the worst UI possible in a security context. as an application developer, setting the network trust level would also be a lot better than having every single application contact firewalld and open a port, with a privilege escalation in between, since it does not assume applications can be trusted.
Posted Dec 19, 2014 5:22 UTC (Fri)
by sjj (guest, #2020)
[Link] (1 responses)
I've never had any problem printing to a network printer or accessing content from a NAS. AFAIK outbound and return traffic has always been allowed. What firewall on Linux makes you click every time for a network connection - I've certainly not seen one?
Posted Dec 19, 2014 5:45 UTC (Fri)
by mcatanzaro (subscriber, #93033)
[Link]
Posted Dec 19, 2014 15:37 UTC (Fri)
by andreasn1 (guest, #88420)
[Link]
I've been trying to use the firewall UI in the past, but it was just too hard to use, since I'm not a network admin. :/
Posted Dec 18, 2014 16:52 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (2 responses)
The next step would seem to be to have a robust way to define what network you are on and whether it should have services offered or not. I think both firewalld and NetworkManager have a concept of zones, there should only need to be two zones, a trusted one which allows all services and an untrusted one which does not allow any services by default, with a policy for applications installing rules on what those rules should be.
As a side note, there is probably a bit of redundancy here in allowing firewall rules with application sharing, ports which are blocked which don't have services on them are of no security consequence whatsoever, if every service that is enabled also has a corresponding rule then the firewall has no traffic it can block that would be of consequence, so the firewall is of no consequence. The only time a packet filter like firewalld provides any value is if there are services which are listening for remote connections on the network that shouldn't be, which can also be fixed by not running or listening in the first place.
So a policy where the firewall is only active on untrusted networks and is disabled completely on trusted networks is probably actually equivalent and requires less maintenance, presuming you can't reliably shut down (and keep down) network sharing services when running on untrusted networks. If the admin adds rules manually that is their own problem.
Posted Dec 19, 2014 3:02 UTC (Fri)
by ebassi (subscriber, #54855)
[Link] (1 responses)
firewalld is basically Fedora-only, and it would require explicitly coding for it. I also don't know how much stable the interfaces are. the main reason why I would not really like apps poking holes in the firewall is because I don't trust applications; the second reason would be that in order to poke a hole in the firewall from a user-launched application would be through a privilege escalation, and that requires constant, nagging, consent — which is the worst. yes, "authorize and remember forever" is a possibility, but then you need to train the users on how to revoke their consent, and that's another can of worm, because now you need two separate UIs and why is everything full of bees… setting the trust level of the network, on the other hand, sounds like a better use of my time as both a user with stuff to get done, and as a developer, with other stuff to get done. I may understand that it does not require weird nerd shibboleth stuff, like port ranges during the installation, but I count that in the plus column.
Posted Dec 19, 2014 18:13 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
I wonder what Android does in this case, does it use the local packet filter or is it just very conscious about services listening on ports.
Posted Dec 19, 2014 0:11 UTC (Fri)
by sjj (guest, #2020)
[Link]
Ah, the good old Gnome "exclude anyone who disagrees" gambit. Very disappointing.
Posted Dec 21, 2014 23:12 UTC (Sun)
by jwarnica (subscriber, #27492)
[Link]
(Open)SuSE kinda has this with /etc/sysconfig/SuSEfirewall2.d/services/[thingy] files; it could be metadata in RPM itself. Java has its java.[policy|security] stuff as well. Yeah, Java. But not conceptually bad. iStuff and Android implements the same general concept (beyond firewall): the developer declares the needed security elevation, and the user says yes or no.
Fedora so much as *asking* the question of "system firewall: yes/no", be it to themselves or to end uses is frightening.
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
- do they ever use their laptop in a coffee shop?
- are there no students using Fedora?
- why should I lower my shields and be vulnerable to my cow-orkers' machines?
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
This is BROKEN!
This is BROKEN!
This is BROKEN!
Except if you want to use HTTPS tunneling or its Ejabberd's web console.
It turns out that it's impossible. Caps are unconditionally dropped during the ID switch.
> http://stackoverflow.com/a/7701793
Erm... You can see that it's an answer by some guy named Cyberax. I've just added a comment saying that it doesn't really work.
Which is even a greater hack.
This is BROKEN!
This is BROKEN!
This is BROKEN!
This is BROKEN!
Ejabberd creates sockets dynamically during the configuration parsing. There's no sharply delimited synchronization point where you can drop the caps.
This is BROKEN!
> Ejabberd creates sockets dynamically during the configuration parsing. There's no sharply delimited synchronization point where you can drop the caps.
This is BROKEN!
This is BROKEN!
This is BROKEN!
1) It doesn't survive ejabberd upgrades.
2) It's not transparent - NOBODY checks file caps.
3) It does not survive the exec() call.
This is BROKEN!
This is BROKEN!
This is BROKEN!
This is BROKEN!
This is BROKEN!
This is BROKEN!
Fedora 21 and its Workstation firewall
asking users security questions is a bad user interface choice.
But not asking them and assuming that they don't want security is an even worse choice.
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Then what's wrong with setting the zone to "home" in NetworkManager for your home wifi? And open ports, even all, in firewalld for the zone. Doesn't this give you the exact functionality without stripping the firewall when you're somewhere else? I certainly don't don't always remember to go through all running applications and services before connecting to a coffee shop wifi. I prefer the computer do these kind of mindless things by itself.
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
I do know that it might increase the risk that my girlfriend will hack my machine, but I guess I'll just have to trust her.
Fedora 21 and its Workstation firewall
Isn't one of the big features of the new firewalld that it offers an API? So wouldn't it make sense for apps that do sharing to programmatically add their rules to the firewall based on the positive user action of turning the sharing feature on?
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall
Fedora 21 and its Workstation firewall