|This article brought to you by LWN subscribers|
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
For many Fedora users, one of the first steps taken after installing a new machine is to turn off SELinux — though SELinux has indeed become less obstructive over time. In a similar vein, many users end up turning off the network firewall that Fedora sets up by default. The firewall has a discouraging tendency to get in the way as soon as one moves beyond simple web-browsing and email applications and, while it is possible to tweak the firewall to make a specific application work, few users have the knowledge or the patience to do that. So they just make the whole thing go away. That's why it has been proposed to turn off the firewall by default for the Fedora 21 Workstation product. While the proposal has been rejected, for now anyway, the reasons behind it remain.
The change proposal reads this way:
As one might imagine, this proposal led to a lengthy discussion once it hit the Fedora development list. To those who oppose the proposal, it is seen as an admission of defeat: firewalling is too hard, so Fedora's developers are simply giving up and, in the process, making the system less secure and repeating mistakes made by other operating systems in the past. Others, though, question the level of real-world security provided by the firewall, especially when many users just end up turning it off anyway. But, behind all the noise, there actually appears to be a sort of consensus on how things should actually work; it's just that nobody really knows how to get to that point.
Nobody, obviously, wants a Fedora system to be insecure by default (unless perhaps they work for the NSA). But there is a desire for the applications installed by the user to simply work without the need for firewall tweaking. Beyond that, the set of services that should work should depend on the network environment that the system finds itself in. When the system is connected to a trusted network (at home, say), more services should be reachable than when it is connected to a dodgy airport wireless network. Fedora's firewalld tries to make the right thing happen in all cases, but the problem turns out to be hard.
Once the firewall is in place, any network service that is not explicitly allowed will not function properly. That is why the first attempt to set up something as simple as an SSH server on a Fedora system is usually doomed to failure. There are a couple of mechanisms that could address this problem, but they have issues of their own. The first possible solution is to provide an API to allow applications to request the opening of a hole in the firewall for a specific port. Firewalld already supports this API via D-Bus, but it is hard to see this API as a full solution to the problem for a couple of reasons:
A potential solution to the second problem (and, perhaps the first) is to put a mechanism in place to notice when an application is trying to listen on a firewalled port and ask the user if the port should be opened. The problem with this approach was nicely summarized by Daniel Walsh, who said: "Nothing worse than asking users security-related questions about opening firewall ports. Users will just answer yes, whether or not they are being hacked." Even if they take the time to answer carefully, users will tend to get annoyed by security questions in short order. As a general rule, the "ask the user" approach tends not to work out well.
An alternative is to try to do the right thing depending on the network the system is connected to. On a trusted network, the firewall could allow almost all connections and services will just work. When connecting to a coffee-shop network, instead, a much tighter firewall would be in place. As it happens, firewalld was designed to facilitate this type of policy as well; it allows the placement of both networks and applications into "zones." When the system is on a network assigned to a specific zone, only applications which have been enabled for that zone will be able to open reachable ports to the world.
The current setup does not lack for zones; indeed, there are nine of them with names that vary from "trusted" to "external," "dmz," or "drop." As Matthias Clasen pointed out, this is far too many zones for most users to know what to do with, and there is no real information about what the differences between them are. Configuration is via a set of XML files; NetworkManager can put networks into zones if one digs far enough into the dialogs, but there is little help for users wanting to know what a specific zone means or how it can be changed.
There seems to be a rough consensus that, if firewalld had a more usable zones system, it could be left enabled by default. The move to disable the firewall is a clear statement that, in some minds at least, firewalld cannot be fixed in the Fedora 21 time frame. There is, however, one approach that might work: reducing the number of zones considerably. In fact, in a related discussion last February, Christian Schaller suggested that all the system needs by default is two zones: trusted and untrusted. When NetworkManager connects to a new network, it can ask the user whether that network is trusted or not and set the firewall accordingly.
This idea seemed to gain some favor in both discussions, but it is not clear that somebody will get around to actually making it work in the near term. That may need to change in the near future, though. On April 23, the Fedora Engineering Steering Committee discussed this proposal and, with a five-to-two vote, rejected it. So the Fedora 21 workstation product will probably have a firewall by default, but how that firewall will work still needs to be figured out.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds