[Ferm] Dual-stacking and IP in variables

Faidon Liambotis paravoid at debian.org
Wed Jul 6 02:47:51 CEST 2011


Hi,

On several dual-stack setups of mine, I tend to have configurations such
as below:
    @def &ALLOW_V4($proto, $port, $srange) = {
        domain ip chain INPUT {
            proto $proto dport $port saddr $srange ACCEPT;
        }
    }
    
    @def &ALLOW_V6($proto, $port, $srange) = {
        domain ip6 chain INPUT {
            proto $proto dport $port saddr $srange ACCEPT;
        }
    }
 
    @def $TRUSTED_V4 = (128.66.1.0/24);
    @def $TRUSTED_V6 = (2001:db8:456::/48);
 
    &ALLOW_V4(tcp, ssh, $TRUSTED_V4);
    &ALLOW_V6(tcp, ssh, $TRUSTED_V6);

This is nice and abstracted but far from ideal, especially considering
that this pattern gets repeated all over the place.

In a perfect world, the call sites should just call
    &ALLOW(tcp, ssh, $TRUSTED);
and be done with it for both address families.

Unfortunately, I haven't been able to find a way to do this.

Thinking of things that /could/ be implemented, I can think of multiple
approaches that could be used, like:

  1. Have $TRUSTED = (128.66.1.0/24 2001:db8:456::/48); code the
     function to ignore the addresses not concering their domain
     (e.g. by having a built-in that can answer on the validity of an
     address)

  2. Same as (1), but have *ferm* ignore statements that are for e.g. an
     ip6 domain but contain an IPv4 address/subnet in saddr.

  3. Have $TRUSTED and &ALLOW() set conditionally per domain.
     Note that contrary to intuition, stanzas like:
        domain ip  { @def $TRUSTED = (128.66.1.0/24);     }
        domain ip6 { @def $TRUSTED = (2001:db8:456::/48); }
     do not work due to scoping limitations of ferm, i.e. $TRUSTED is
     not defined outside of the domain { } stanza. Same applies for:
        @if @eq($DOMAIN, ip6) { … } @else { … }
     and other variations I could think of, including messing with @include
     to bypass the scoping limitations.

I had a quick glance at the code and it seems that all of the above are
quite difficult to implement without some major restructuring.

Any other ideas? Am I missing something obvious?

Regards,
Faidon


More information about the Ferm mailing list