[ale] Firewalld is incomplete

[Alex Carver]

On 2019-01-27 09:47, Solomon Peachy wrote:
> On Sun, Jan 27, 2019 at 09:18:28AM -0800, Alex Carver via Ale wrote:
>> Perhaps but it seems like overkill to have a Python script (at the
>> moment I'm overlooking the imposed need to run an interpreter on your
>> firewall) managing iptables when, according to the documentation, any
>> rule that isn't a very simple one has to use what firewalld calls "rich
>> rules" which look exactly like a more verbose version of an iptables
>> command.  It seems if you're going to have to issue a command that looks
>> just like an iptables command then why not cut the middleman and run
>> iptables?  It already shows in the flow chart that it's just a wrapper
>> to iptables anyway (no direct access to the kernel).
> 
> The purpose of firewalld is to abstract away the specific network 
> interfaces, operational modes, and firewall implementation from 
> applications (&| services) that only care about firewalling enough to 
> say "allow in the packets I care about" or "set my laptop up to be a 
> hotspot using my tethered cell phone"
> 
> For "workstation" or "server" systems, it's quite useful.  It's also 
> good enough for a typical home gateway user, who only cares about 
> automatically NATting the system's internet connection.  Beyond that, ie 
> for "router" systems, it's not so terribly useful.

The documentation does appear to show that it really is intended to
control only basic inbound connections but I would argue that missing
outbound configurations doesn't make it overly useful for workstations
or servers which need outbound rules.

> 
> (firewalld is inadequate to replace what I'm using for my home 
>  gateway, but couple of years back it gained sufficient utility to 
>  automagically power my camper trailer's hotspot, including 
>  properly interacting with the VPN back to home...)

It certainly wouldn't work for my router.  What is it that it does for
you in your trailer configuration that wasn't possible before it existed?

> 
> It's different from UPnP in that there's deliberately no *remote* 
> interface that allows arbitrary ports opened in the firewall.  All 
> command and configuration is localhost (via dbus) only.

Fair enough, as long as only local the that does help some but it does
still add an attack surface even if root isn't compromised.

> 
> (If the local system is sufficiently compromised to allow twiddlling of 
>  firewalld, then it's sufficiently compromised to twiddle iptables/etc 
>  directly..)

That's half true.  If the local system has a user account (but not root)
compromised then they don't have access to iptables since it requires
root.  A dbus interface can have a compromise or access vector
independent of root because the user account could have been granted
access to dbus (whether accidentally or for some other purpose).  I see
plenty of configuration examples just searching for dbus non-root to see
that it's possible to do.  It just makes for an extra attack surface
which makes me nervous (nevermind that it's an entire python script so
you're depending on ptyhon to be safe).