firewalld / iptables.service past F17

[Oron Peled]

On Monday, 23 בApril 2012 18:56:23 Reindl Harald wrote:
> Am 23.04.2012 17:32, schrieb Miloslav Trmač:
> > On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald <h.reindl at thelounge.net> 
wrote:
> >> http://fedoraproject.org/wiki/Features/firewalld-default
> >>
> >>> An explicit transition is planned after Fedora 18 with dropping support 
for the
> >>> static firewall with system-config-firewal/lokkit. A migration from the 
static
> >>> firewall model will be needed then.

Looks like this transition (as is currently planned) is going to
break many setups. I want to show the three following use-cases
which may be severely broken by this transition.

1. The simplest desktop case (firewalld is designed for such users).
   This is what I personally use on most of my desktops/laptops:

   * The user previously only used system-config-firewall (without
     custom rules -- we talk about simplest case)

   * The firewalld package does not even try to convert existing rules
     (just looked at the .spec file for the post*/pre*/trans*)

   * Results:
     - The user looses all her existing firewall settings without a warning
       (security).

     - If they had NAT (masquarading) -- pooof, no more Internet for you...

     - Almost all record of their previous settings is lost (sans .rpmsave)

     - If the poor user make another mistake (e.g: tries to re-install
       system-config-firewall), it may even clobber the .rpmsave
       [this is DATA-LOSS!]

2. Custom made firewall (e.g: hand-written script. I personally
   use this in rare/complex cases):

   * It obviously cannot be migrated automatically.

   * That's OK, as someone that can maintain the custom script, can
     migrate it manually.

   * But:
     - Just like item 1. above, we cannot take the risk that old
       data (e.g: existing /etc/sysconfig/iptables) would be somehow
       clobbered by install/upgrade/re-install of
       firewalld/system-config-firewall.
       [although the "customization" user is more likely to have backup
        of said script, unlike the naive user from item 1.]

     - As others mentioned before, this use-case may contain features
       not (yet/ever?) in firewalld. So they need a (long-term) way
       to keep using their custom scripts (yes, even in F-21 unless
       by that time firewalld can have the full power of raw
       iptables script).
       [note: however, this use-case does *not* need system-config-firewall]

3. Complex firewall made by external tools (similar to 2.)
   My personal example is fwbuilder (packaged in Fedora):

   * I use it to centrally manage several firewalls

   * If firewalld becomes default after some upgrade, then:
     - Poof, some of these cannot be accessed (NAT...)

     - ... and alternative access (physical) is Hmmm.... problematic

     - I would call this super "uncool" (just a bit less uncool
       than the potential data-loss I mentioned before...)

Summary:
  * Regretfully, I think it's clear that firewalld as *default* is
    a complete show-stopper (for now).

  * One (not hard) improvement is to preserve old data. E.g:
    - During firewalld postinst (in install, upgrade is not
      the problem here), save a copy of all previous iptables
      config in a well defined location -- e.g:
           /etc/firewalld/old-iptables-data

    - Make this data time-stamped to prevent overwriting in
      repeated (maybe mistaken) install/remove attempts. E.g:
           /etc/firewalld/.../2012-04-24_02-28/iptables
           /etc/firewalld/.../2012-04-24_02-28/iptables-config

    - Also echo a message about it to stderr (I know its against
      the policy, but critical data-loss is more important IMO).

  * Try to migrate system-config-firewall data:
    - That is harder, but even doing only the "no-custom-rules" case
      would prevent tons of problems for most (normal/naive) users.

    - This would help even without/before firwalld is default.

  * Make installation/activate of firewalld optional even after
    it is good enough to be default:
    - Custom/complex setups will not be migrated (surely not before
      firewalld cannot cover the flexibility of raw iptables)

    - So when people install servers, they may not want firewalld
      at all (regardless of system-config-firewall existance)

    - Don't assume a "live-cd" is only used only for desktop installs.
      Many people (me included) install servers from a live-cd
      and add the rest later.

      Why? Because many times these are isolated servers (not on my
      kickstart-configured network), the live-cd image is smaller
      to download than a DVD, its already in my pocket on a DOK,
      etc, etc.

    - So I think that even when firewalld is (eventually) good enough
      for a *default* install and even when system-config-firewall will
      already be a relic from the past -- we should allow power-users
      not to install it in the first place.

      I.e: it should be a *suggested* option.
      From a (future) UI perspective its installation should IMO behave
      similar to smolt. I.e: ask for install (default=yes), allow to
      choose "no", if "no" is chosen, re-confirm with an explanation.

  * Wishfull thinking for longer-term:
    - Existing high-level tools, may be persuaded to generate firewalld
      commands/config instead of low-level iptables config.

    - As an example fwbuilder already has plugins to generate rules for
      several engines (iptables, ipfilter, cisco, etc.) in some futuristic
      pipe-dream it may have a firewalld plugin.

Cheers,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
Make it idiot proof and someone will make a better idiot.
credit: http://www.jr.co.il/humor/signatur.txt