Jud Craft wrote:
On Mon, Jun 15, 2009 at 4:52 AM, Thomas Woerner<twoer...@redhat.com> wrote:
The major problem with a /etc/iptables.d direcory with files provided by
packages are that you can not say in the end what your firewall will look
like: Is the firewall is open for a specific service/host/network or not.
The files are text blobs and therefore there is no way to say what they will
do.

If you have packages dropping in some firewall rules into the firewall
without the ability for activation/deactivation and also sorting of the
rules, then you could get into unexpected behaviour and also big security
risks.

Well, ideally, system-config-firewall should support iptables rules
(in text blobs) AS IS, rather than having its own set of custom rules
that are completely obviously to the standard method for specifying
them.

Custom rules in system-config-firewall are text blobs in the iptables-save format to make it possible to add rules, s-c-fw is not able to handle.

And then, it should be able to display the state of the firewall in
its entirety, not just its own custom rules.  If it's going to be an
abstraction around iptables, it should be a good one, and
actually...you know, abstract iptables.  Not just add another
non-exclusive conflicting interface for specifying rules on top.

Just use service iptables status. It is displaying the current active firewall. Building an up-to-date abstraction layer around iptables is nearly impossible. There are too many changes going on in netfilter and iptables.

Or, pull a fontconfig, and obsolete the iptables text files, requiring
everyone to go through an official API (firewallconfig) or somesuch to
specify behaviors.  Then packages could use this system, rather than
dropping in random text files, and these settings could then be
centralized and monitored by a tool like system-config-firewall.

A start for this is done, please have a look at the tool.

Just thoughts.


Thomas

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reply via email to