From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next] netfilter: x_tables: add context to know if extension runs from nft_compat
Date: Mon, 2 Mar 2015 16:21:36 +0100 [thread overview]
Message-ID: <20150302152136.GA3075@salvia> (raw)
In-Reply-To: <20150302143642.GC11849@acer.localdomain>
On Mon, Mar 02, 2015 at 02:36:47PM +0000, Patrick McHardy wrote:
> On 02.03, Pablo Neira Ayuso wrote:
> > On Mon, Mar 02, 2015 at 02:19:00PM +0000, Patrick McHardy wrote:
> > > On 02.03, Pablo Neira Ayuso wrote:
> > > > On Mon, Mar 02, 2015 at 01:19:01PM +0000, Patrick McHardy wrote:
> > > > > >
> > > > > > 3) SYMPROXY6. Don't check for e->ipv6.flags, we can instead check
> > > > > > for e->ipv6.proto as other extensions do, if zero then it doesn't
> > > > > > fulfill the dependency.
> > > > >
> > > > > But we don't perform a protocol match in ip6_tables if the IP6T_F_PROTO
> > > > > flag is not given. ip6_tables differs from ip_tables in this regard.
> > > >
> > > > This just makes sure that SYNPROXY6 is not called for non-tcp traffic
> > > > in the rule loading path, which should be OK.
> > >
> > > Yeah, but for ip6_tables we actually need the check the way it is,
> > > without IP6T_F_PROTO we will not perform the protocol match.
> >
> > if (!(e->ipv6.flags & IP6T_F_PROTO) ||
> > e->ipv6.proto != IPPROTO_TCP ||
> > e->ipv6.invflags & XT_INV_PROTO)
> > return -EINVAL;
> >
> > e->ipv6.flags & IP6T_F_PROTO seems redundant to me, it just says
> > e->ipv6.proto is set.
>
> No, it also instructs ip6_tables to actually match on that value.
>
> > If that flag is not set, then e->ipv6.proto is left unset. But the
> > effect should be the same since 0 != IPPROTO_TCP.
> >
> > This is just relaxing the validation in SYNPROXY6 to only check
> > e->ipv6.proto which is what nft_compat sets.
> >
> > Am I missing anything?
>
> Yes, ip6_tables only performs the protocol match when that flag is set.
> Look:
>
> /* look for the desired protocol header */
> if((ip6info->flags & IP6T_F_PROTO)) {
> ...
> if (ip6info->proto == protohdr) {
>
> This is where ip6_tables and ip_tables are different, ip_tables
> takes ipinfo->proto as an indicator, ip6_tables the flag.
I'm not altering the ip6_tables core logic.
ip6tables from userspace sets IP6T_F_PROTO, the core handles things as
you described, but SYNPROXY6 only checks if e->ipv6.proto != IPPROTO_TCP.
REJECT6 does exactly the same that I need:
if (e->ipv6.proto != IPPROTO_TCP ||
(e->ipv6.invflags & XT_INV_PROTO)) {
pr_info("TCP_RESET illegal for non-tcp\n");
return -EINVAL;
}
I just want to relax the check in SYNPROXY6, so it works fine with
nft_compat. I think nothing will break.
next prev parent reply other threads:[~2015-03-02 15:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 13:11 [PATCH nf-next] netfilter: x_tables: add context to know if extension runs from nft_compat Pablo Neira Ayuso
2015-03-02 13:19 ` Patrick McHardy
2015-03-02 14:03 ` Pablo Neira Ayuso
2015-03-02 14:19 ` Patrick McHardy
2015-03-02 14:30 ` Pablo Neira Ayuso
2015-03-02 14:36 ` Patrick McHardy
2015-03-02 15:21 ` Pablo Neira Ayuso [this message]
2015-03-02 15:30 ` Patrick McHardy
2015-03-02 13:19 ` Florian Westphal
2015-03-02 13:27 ` Patrick McHardy
2015-03-02 13:58 ` Pablo Neira Ayuso
2015-03-02 13:50 ` Pablo Neira Ayuso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150302152136.GA3075@salvia \
--to=pablo@netfilter.org \
--cc=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).