[ale] Firewalld is incomplete

[Jim Kinney]

Anyone that can attack a Linux box by futzing with firewalld is already a guru and had root before you installed that OS. :-)

On January 27, 2019 1:45:41 PM EST, Alex Carver via Ale <ale at ale.org> wrote:
>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).
>_______________________________________________
>Ale mailing list
>Ale at ale.org
>https://mail.ale.org/mailman/listinfo/ale
>See JOBS, ANNOUNCE and SCHOOLS lists at
>http://mail.ale.org/mailman/listinfo

-- 
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20190127/7ab26b08/attachment.html>