netdev - Re: [PATCH 07/31] netfilter: ctnetlink: Support L3 protocol-filter on flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51b7d27b-a67e-e3c6-c574-01f50a860a5c@6wind.com>
Date:   Thu, 2 May 2019 09:28:44 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Kristian Evensen <kristian.evensen@...il.com>
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        Netfilter Development Mailing list 
        <netfilter-devel@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH 07/31] netfilter: ctnetlink: Support L3 protocol-filter on
 flush

Le 01/05/2019 à 10:47, Kristian Evensen a écrit :
> Hello,
> 
> On Thu, Apr 25, 2019 at 12:07 PM Nicolas Dichtel
> <nicolas.dichtel@...nd.com> wrote:
>> Since this patch, there is a regression with 'conntrack -F', it does not flush
>> anymore ipv6 conntrack entries.
>> In fact, the conntrack tool set by default the family to AF_INET and forbid to
>> set the family to something else (the '-f' option is not allowed for the command
>> 'flush').
> 
> I am very sorry for my late reply and for the trouble my change has
> caused. However, I am not sure if I agree that it triggers a
> regression. Had conntrack for example not set any family and my change
> caused only IPv4 entries to be flushed, then I agree it would have
> been a regression. If you ask me, what my change has exposed is
> incorrect API usage in conntrack. One could argue that since conntrack
> explicitly sets the family to AF_INET, the fact that IPv6 entries also
> has been flushed has been incorrect. However, if the general consensus
> is that this is a regression, I am more than willing to help in
> finding a solution (if I have anything to contribute :)).
I understand your point, but this is a regression. Ignoring a field/attribute of
a netlink message is part of the uAPI. This field exists for more than a decade
(probably two), so you cannot just use it because nobody was using it. Just see
all discussions about strict validation of netlink messages.
Moreover, the conntrack tool exists also for ages and is an official tool.


Regards,
Nicolas