On 2017-01-03 09:56, David Sommerseth wrote:
On 03/01/17 05:59, jdow wrote:
...
The lockdown-whitelist thing is more or less a "but why?" component.
lockdown in firewalld jargon is more like "which component/user may
modify the firewall if the firewall configuration have been locked down".
When firewalld is set into locked-down mode, no-one is able to
manipulate the firewall. Otherwise, anyone granted admin privileges (as
defined in the PolicyKit policy for the firewalld component) may
manipulate the firewall. So it tightens the access, regardless if
PolicyKit grants access. The default policy have uid=0,
firewall-config, NetworkManager and libvirtd in this whitelist.
Remember that firewalld provides an API over D-Bus for dynamic firewall
updates, so this is kind of to "seal" the configuration without breaking
any component depending on manipulating the firewall as the system is
running. NetworkManager and libvirt are two components which adjusts
the firewall on-the-fly, depending on which network you're connected to
or which VMs have been started, and so on.
That still leaves me mumbling and led me down a midget rabbit hole. The
"iptables" command is 777 root root system_u:object_r:bin_t:s0; but, that's OK.
It's a link - to xtables-multi, which is rwxr-xr-x. root root
system_u:object_r:iptables_exec_t:s0. Waitaminit says I to meself. (or is it me
to iself? Whatever) Let's give that a try.... The results are reassuring:
===8<---
[jdow@whereever ~]$ xtables-multi iptables -L -v
iptables v1.4.21: can't initialize iptables table `filter': Permission denied
(you must be root)
Perhaps iptables or your kernel needs to be upgraded.
===8<---
I guess the ancient philosophy of one task one command is passe' and now a
monstrosity like xtables-multi finds itself masquerading as iptables and about a
dozen other things. I have a skew sense of humor so I find that amusing. I see
it's been that way for some years now even in 6.x. I just never had cause to
look for this. Somebody liked the inetd model later called xinetd. (Speaking of
which, I notice systemd seems to have subsumed even that functionality. It's
good from a central management standpoint. It's yet another unclear puzzle when
initially trying to wrap one's mind around systemd.)
Preserving the lockdown file for something that is removed from the system,
though, seems to be silly to my fevered brain.
Gee, my rant has led to some good learning and a slightly fascinating rabbit
hole, as well as the frustrating systemd mile deep rabbit hole.
{^_^}
