Firewall portion of plug should use FirewallD instead of ufw

[elementaryBot]

This plug currently requires ufw and executes ufw commands through pkexec to apply rules.

However, a better approach would be to use FirewallD1 and communicate with it via D-Bus. This also has the advantage of making it less brittle as communication via D-Bus is easier to manage than pkexec calls and allows for more granular privilege control (reducing the need to escalate privileges to merely when you need to write new rules).

FirewallD also supports a service-oriented model for managing firewall rules. For example, if you're controlling via the CLI, to close the SSH port, you can just do "firewall-cmd --remove-service=ssh" instead of having to specify to remove port 22. This enables you to make the plug simpler and describe things in terms of services, rather than in terms of ports.

You can, of course, still specify ports and stuff. Via the CLI, it's merely "firewall-cmd --(add|remove)-port=/(tcp|udp)".

It also has a concept of zones, so you can expose that if you'd like as well.

Everything about FirewallD is available via D-Bus, and all the tools currently written use D-Bus to communicate with it.

FirewallD is available as "firewalld" in Ubuntu.

Launchpad Details: #LP1639775 Neal Gompa - 2016-11-07 12:15:26 +0000

---

There is a bounty for this issue on Bountysource

[Conan-Kudo]

@tintou Can you rebase the patch from Launchpad and provide it as a PR against this? @decathorpe and I use this on Fedora to integrate with firewalld.

[codygarver]

This is a good case for conditional compilation IMO. Since we have to support UFW for at least as long as we support Loki. It would make it easier to release future versions directly from master, no extra distro patches.

[danirabbit]

I'm going to remove the "In Progress" label since there is not currently a PR in GitHub for this

[CameronNemo]

I feel that this should not be determined at compile time, but at runtime. Some people use ufw on fedora and others use firewalld on Ubuntu.

[Conan-Kudo]

That would make everything a hell of a lot more complicated. How would we handle rule translation? This plug is mostly a thin wrapper around the interface for the firewall, so it gets to have no state of its own. If it had to support swapping at runtime, it'd have to actually track data and actively migrate it.

[CameronNemo]

I don't think migrating state is necessary, the plug would just manage the state of whatever firewall tool is currently active/installed.

But if you think it would be too complicated to determine the backend at runtime, I guess two packages for the differently compiled versions of the plug is not too burdensome.