Distributions
Fedora's firewall furor
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:
- Firewalld is a Fedora-specific project, so its API, too, is naturally
a Fedora-only affair. As a result, application developers are
reluctant to include firewalld support in their code; it's an
additional maintenance burden for a relatively small group of
additional users.
- Users may not want an application to be able to silently perforate the firewall in all settings, especially if they are worried about malicious software running on their own systems.
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.
Brief items
Distribution quotes of the week
Debian 6.0 to get long-term support
The Debian project has announced that the security support period for the 6.0 ("squeeze") release has been extended by nearly two years; it now runs out in February 2016. At the end, squeeze will have received a full five years of security support. "squeeze-lts is only going to support i386 and amd64. If you're running a different architecture you need to upgrade to Debian 7 (wheezy). Also there are going to be a few packages which will not be supported in squeeze-lts (e.g. a few web-based applications which cannot be supported for five years). There will be a tool to detect such unsupported packages."
Ubuntu 14.04 LTS (Trusty Tahr) released
Ubuntu has announced the release of its latest long-term support distribution: Ubuntu 14.04 LTS (aka "Trusty Tahr"). The release notes have all the details. It comes in a multitude of configurations, for desktops, servers, the cloud, phones, and tablets; also in many flavors: Kubuntu, Edubuntu, Xubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, and Ubuntu Studio. "Ubuntu 14.04 LTS is the first long-term support release with support for the new "arm64" architecture for 64-bit ARM systems, as well as the "ppc64el" architecture for little-endian 64-bit POWER systems. This release also includes several subtle but welcome improvements to Unity, AppArmor, and a host of other great software."
Newsletters and articles of interest
Distribution newsletters
- DistroWatch Weekly, Issue 555 (April 21)
- Five Things in Fedora This Week (April 22)
- Ubuntu Weekly Newsletter, Issue 364 (April 20)
Shuttleworth: U talking to me?
Ubuntu's Trusty Tahr has been released and that means it's time for a new development branch. Mark Shuttleworth has announced the name of the next Ubuntu release. "So bring your upstanding best to the table – or the forum – or the mailing list – and let’s make something amazing. Something unified and upright, something about which we can be universally proud. And since we’re getting that once-every-two-years chance to make fresh starts and dream unconstrained dreams about what the future should look like, we may as well go all out and give it a dreamlike name. Let’s get going on the utopic unicorn."
Emmabuntüs: A philanthropist’s GNU/Linux (muktware)
Muktware takes a quick look at Emmabuntüs. "Emmabuntüs is a desktop GNU/Linux distribution which originated in France with a humanitarian mission. It was designed with 4 primary objectives – refurbishing of computers given to humanitarian organizations like the Emmaüs communities, promoting GNU/Linux among beginners, extending the life of older equipments and reducing waste by over-consumption of raw materials."
Page editor: Rebecca Sobol
Next page:
Development>>