LWN: Comments on "Fedora 21 and its Workstation firewall"

This is BROKEN!

foom — Fri, 26 Dec 2014 21:37:19 +0000

Works fine if you set up the iptables rules correctly. Local packets don't go through PREROUTING/POSTROUTING, so you also should add a rule on the OUTPUT nat table for packets destined for interface lo.

This is BROKEN!

Cyberax — Fri, 26 Dec 2014 18:37:44 +0000

Except it does not work with localhost, as far as I remember.

This is BROKEN!

cesarb — Fri, 26 Dec 2014 09:28:55 +0000

You can also use iptables to proxy from a low port to a high port.

(It exposes a huge kernel written in C to the network, but it's already exposed anyway, so...)

This is BROKEN!

mathstuf — Fri, 26 Dec 2014 04:25:37 +0000

Is it something an nginx extension could handle to proxy?

This is BROKEN!

Cyberax — Thu, 25 Dec 2014 19:03:16 +0000

It's more complicated. Jabber's SSL tunneling uses a custom non-HTTP protocol over the HTTPS port. So you can't use nginx to do proxying.

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.

Fedora 21 and its Workstation firewall

job — Thu, 25 Dec 2014 11:38:47 +0000

This was my experience from running a unix lab with only public ip addresses. Altough that was a decade ago, so the threat models might have changed a bit since then.

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").

This is BROKEN!

job — Thu, 25 Dec 2014 11:32:37 +0000

Wouldn't a more sane default be for ejabberd to bind a dedicated (high) port, since there might be a lot of packages on the system providing a web based control panel?

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.

Fedora 21 and its Workstation firewall

sjj — Tue, 23 Dec 2014 20:26:04 +0000

Thanks, I must have looked in the wrong sections.

Fedora 21 and its Workstation firewall

raven667 — Tue, 23 Dec 2014 17:23:02 +0000

While I do think we need to keep reviewing the justification for having a packet filter, so playing devils advocate and exploring what would happen without it is good, it I also true that there are a number of network services which desktop users run whose threat models don't cover being accessible from untrusted computers. A firewall policy which blocks access when on a shared network would be good. Only listening on FE80::/64 addresses is a good idea too.

Fedora 21 and its Workstation firewall

mcatanzaro — Tue, 23 Dec 2014 14:00:03 +0000

Your system was compromised through a socket above 1024 that was opened by a service that you did not want running in the first place? The presence of such a service on your system would be expected to coincide with a firewall rule for that service if you wanted the service to work, and if you did not want the service to work then it would not be installed, so I presume an accident occurred such that the service was both installed and enabled without your knowledge? So the issue was that you accidentally enabled a system service that you did not want to enable, and then that service was compromised because you didn't have a firewall rule in place to break that service?

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....

Fedora 21 and its Workstation firewall

brouhaha — Tue, 23 Dec 2014 06:48:39 +0000

If you never have had the joy of having to clean a system that was compromised though a socket above 1024, you've led a charmed life.

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.

Fedora 21 and its Workstation firewall

mchapman — Tue, 23 Dec 2014 04:21:56 +0000

> OK, so I did an upgrade to 21. I can live with it, now that I know about the change. Not that I would have known about it had I only read Fedora 21 release notes.

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.

Fedora 21 and its Workstation firewall

sjj — Tue, 23 Dec 2014 03:36:04 +0000

OK, so I did an upgrade to 21. I can live with it, now that I know about the change. Not that I would have known about it had I only read Fedora 21 release notes.

Seriously, a big change in default security policy, and no mention in the release notes? I searched for "fire" - did I miss it?

Fedora 21 and its Workstation firewall

jwarnica — Sun, 21 Dec 2014 23:12:40 +0000

The (an!) other possibility would be that apps declare their desired ports, and either on installation, or execution (up to the user, either way could be chosen, IDK which) the firewall just allows access to known, "officially" installed apps.

(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

raven667 — Fri, 19 Dec 2014 18:13:13 +0000

As I said later, putting interfaces in zones and dropping the firewall in a trusted home zone and leaving it blocking all inbound (and outbound service advertisements too) when in a foreign network will get you most of the way there. There still needs to be some level of coordination between the distros and app makers though, standard APIs to manage security zones that work across Fedora, Debian (and derivatives), SuSE and others. If you did want to get down to individual rules being managed by the apps then having a standard API with that granularity would be important, maybe adopting the firewalld API for other distro tools, or adopting firewalld across distros or making a new API or whatever.

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.

Fedora 21 and its Workstation firewall

andreasn1 — Fri, 19 Dec 2014 15:37:56 +0000

Turning off firewalld suddenly makes things work in my home network. I'm able to browse media, print things etc.
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.

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. :/

Fedora 21 and its Workstation firewall

mcatanzaro — Fri, 19 Dec 2014 05:45:06 +0000

The change is that we effectively default to the home zone, so that stuff works and users don't hate Fedora. (Although home remains a technically separate zone, because firewalld zones are insane; hopefully that can get fixed eventually)

Fedora 21 and its Workstation firewall

mcatanzaro — Fri, 19 Dec 2014 05:40:34 +0000

Why do you think this is a significant reduction in security? What new threats will you be vulnerable to that the F20 firewall would have protected you from?

Fedora 21 and its Workstation firewall

sjj — Fri, 19 Dec 2014 05:22:37 +0000

> 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,

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.

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?

Fedora 21 and its Workstation firewall

mcatanzaro — Fri, 19 Dec 2014 05:16:20 +0000

This comes up every time there is a setting that two reasonable people might want to set differently. The answer is that it's not reasonable to fit every configuration setting under the sun into the installer, and option n is not really much more or less special than option m. Plus, installing Fedora Workstation should be simple, so anything that can reasonably be set after installation does not belong in the installer.

Fedora 21 and its Workstation firewall

mcatanzaro — Fri, 19 Dec 2014 05:15:08 +0000

- have they actually worked in small/midsize companies and observed security practices? Hint: not great.

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?

Fedora 21 and its Workstation firewall

mcatanzaro — Fri, 19 Dec 2014 04:59:11 +0000

Not at all -- Fedora Workstation is intended for desktop and laptop computers in any environment.

The looser firewall config is actually specifically intended for home users. I presume media sharing is not very common in corporate environments.

Fedora 21 and its Workstation firewall

ebassi — Fri, 19 Dec 2014 03:02:25 +0000

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.

Fedora 21 and its Workstation firewall

ebassi — Fri, 19 Dec 2014 02:57:19 +0000

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.

This is BROKEN!

Cyberax — Fri, 19 Dec 2014 02:54:11 +0000

Yes, and that's why it worked when I was writing the answer. I have set caps bits on ejabberd, so my solution 'worked'.

However, it's a very brittle:
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!

foom — Fri, 19 Dec 2014 02:35:00 +0000

> Erm... You can see that it's an answer by some guy named Cyberax.

Haha, did not see that. :)

You can use filesystem caps on the ejabberd binary now at least, can't you?

Fedora 21 and its Workstation firewall

sjj — Fri, 19 Dec 2014 00:11:08 +0000

"I think a lot of people also need to remember that workstation isn't built for them, and that's okay."

Ah, the good old Gnome "exclude anyone who disagrees" gambit. Very disappointing.

Fedora 21 and its Workstation firewall

sjj — Fri, 19 Dec 2014 00:07:19 +0000

Yes, and I find the "protected by corporate firewall" excuse pretty damn feeble.

- have they actually worked in small/midsize companies and observed security practices? Hint: not great.
- 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

sjj — Fri, 19 Dec 2014 00:00:48 +0000

> I don't know about others, but the first thing I always do on a fresh fedora system is sudo systemctl stop firewalld && systemctl disable firewalld

Why?

This is BROKEN!

Cyberax — Thu, 18 Dec 2014 19:42:28 +0000

Yes, I understood that. That's how authbind works (except that it uses a small privileged helper).

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.

This is BROKEN!

cesarb — Thu, 18 Dec 2014 19:39:43 +0000

> > 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.
> Ejabberd creates sockets dynamically during the configuration parsing. There's no sharply delimited synchronization point where you can drop the caps.

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.

This is BROKEN!

Cyberax — Thu, 18 Dec 2014 19:36:24 +0000

I don't think Erlang can send the actual sockets. And then there's a question of reliability (you suddenly start to depend on the dispatcher process functioning correctly, even in cases of OutOfMemory conditions).

> 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.
Ejabberd creates sockets dynamically during the configuration parsing. There's no sharply delimited synchronization point where you can drop the caps.

This is BROKEN!

cesarb — Thu, 18 Dec 2014 19:33:13 +0000

Ejabberd is written in Erlang, right? Could it use two Unix processes, the normal one and one running as root (with all caps except binding to low ports dropped and no_new_privs set) to listen on low ports and relay whatever is needed over Erlang's IPC?

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.

This is BROKEN!

Cyberax — Thu, 18 Dec 2014 19:14:55 +0000

Doesn't work. Ejabberd creates sockets depending on its configuration, and it can even be reconfigured at runtime.

This is BROKEN!

meyert — Thu, 18 Dec 2014 19:05:50 +0000

let systemd take the port and give it to the service via StandardInput=socket !

Fedora 21 and its Workstation firewall

meyert — Thu, 18 Dec 2014 19:03:09 +0000

I think most people that install Fedora 21 on their laptops will use the Workstation flavour and not just use it in an company network

Fedora 21 and its Workstation firewall

raven667 — Thu, 18 Dec 2014 16:52:17 +0000

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? If I go into the settings panel and turn on filesharing, couldn't it prompt for credentials at that point and both enable the service and install the firewall rule (and remove it if I turn sharing off)? Plumbing the rules in at the time you need them seems to be the whole point.

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.

Fedora 21 and its Workstation firewall

raven667 — Thu, 18 Dec 2014 16:07:27 +0000

We really have to inventory what information is available to the machine at the time the security decision needs to be made whether a network is "trusted" or not, in the best case you might have a device with GPS and could geo-fence but more likely you have to infer the location by looking at the IP/MAC of the router and SSID/MAC of APs that can reach you, if you keep a database of what your "trusted" location should look like. This is essentially the lowest level of network fingerprint identification and is trivially forgable, so that's a big caveat, kind of like the fact that most devices will probably connect to any AP broadcasting "attwifi" or "linksys" and will mindlessly start sharing sensitive data over highly suspect connections.

Fedora 21 and its Workstation firewall

nedrichards — Thu, 18 Dec 2014 15:20:33 +0000

Exactly. Well said - and the prevalence of web pages telling people how to do just that is a clear indictment of the previous policy.

This is BROKEN!

Cyberax — Thu, 18 Dec 2014 14:08:14 +0000

> Doesn't xmpp usually use port 5222?
Except if you want to use HTTPS tunneling or its Ejabberd's web console.

> 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.
It turns out that it's impossible. Caps are unconditionally dropped during the ID switch.

> See e.g.
> 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.

> Alternatively you can use authbind (which, these days, years later, does actually support IPv6)
Which is even a greater hack.

And all of that for something that does not add any real security.