netfilter buglog - Nov 2018 - [Bug 1290] New: ptables: nftables layer breaks ipsec/policy keyword

https://bugzilla.netfilter.org/show_bug.cgi?id=1290

            Bug ID: 1290
           Summary: ptables: nftables layer breaks ipsec/policy keyword
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: iptables over nftable
          Assignee: pablo at netfilter.org
          Reporter: arturo at debian.org

Forwarded from Debian https://bugs.debian.org/912977

[...]
Some keywords are not supported (like the 'policy' keyword for
IPsec transforms). The bad part is, these rules are inserted
*without* the matches, which makes in some cases your firewall useless.

For ex:
# iptables -F
# iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --mode tunnel -o
eth0 -j ACCEPT
# echo $?
0
# nft list ruleset
<cut>
        chain OUTPUT {
                type filter hook output priority 0; policy accept;
                oifname "eth0"  counter packets 90 bytes 26085 accept
        }
}

As you can see, the inserted rule allows everything, while the expected
behavior would be 'only if going through an IPsec tunnel'.
Even worse: inserting the rule did not fail.

Until the 'ipsec' (or 'secpath') keyword works properly (and
supports
all options), an acceptable behavior would be to reject the rule if one
or more keywords are not supported by nftables.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20181106/e6eebcc2/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1290

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de

--- Comment #1 from Florian Westphal <fw at strlen.de> ---
(In reply to Arturo Borrero Gonzalez from comment #0)
> Forwarded from Debian https://bugs.debian.org/912977
> 
> [...]
> Some keywords are not supported (like the 'policy' keyword for
> IPsec transforms). The bad part is, these rules are inserted
> *without* the matches, which makes in some cases your firewall useless.
> 
> For ex:
> # iptables -F
> # iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --mode tunnel
> -o eth0 -j ACCEPT
> # echo $?
> 0
> # nft list ruleset
> <cut>
>         chain OUTPUT {
>                 type filter hook output priority 0; policy accept;
>                 oifname "eth0"  counter packets 90 bytes 26085
accept
>         }
> }
This nft binary isn't linked against libxtables and thus won't show
the policy match.  The rule *does* contain/use -m policy via nft_compat
expression.
> As you can see, the inserted rule allows everything, while the expected
> behavior would be 'only if going through an IPsec tunnel'.
> Even worse: inserting the rule did not fail.
iptables -A doesn't fail because this works.
> Until the 'ipsec' (or 'secpath') keyword works properly
(and supports
> all options), an acceptable behavior would be to reject the rule if one
> or more keywords are not supported by nftables.
That would break a lot of things.

I'm not sure what best course of action is.

We could alter nft so it produces minimum info when libxtables isn't
available,
e.g.:
chain OUTPUT {
   oifname "eth0" # xt_policy counter packets 0 bytes 0 accept

This is easy to do, however, this doesn't allow restore via nftables either.
We could make nftables intentionall break ruleset:

chain OUTPUT {
   oifname "eth0" nft_compat: xt_policy could not be translated #
ERROR bytes 0

or add a drop

chain OUTPUT {
   oifname "eth0" drop # ERROR xt_policy cannot be used from nft

or something like that.

Not sure. xt_policy.c in libxtables lacks translation for most of its options
so just linking nft with libxtables won't work either.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20181106/355bdb1c/attachment.html>