netdev - Re: [PATCH] netfilter/nflog: nflog-range does not truncate packets

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] [day] [month] [year] [list]

Message-ID: <57641AA7.70709@akamai.com>
Date:	Fri, 17 Jun 2016 11:43:35 -0400
From:	Vishwanath Pai <vpai@...mai.com>
To:	Pablo Neira Ayuso <pablo@...filter.org>
Cc:	"Lubashev, Igor" <ilubashe@...mai.com>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"kadlec@...ckhole.kfki.hu" <kadlec@...ckhole.kfki.hu>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"coreteam@...filter.org" <coreteam@...filter.org>,
	"Hunt, Joshua" <johunt@...mai.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"pai.vishwain@...il.com" <pai.vishwain@...il.com>
Subject: Re: [PATCH] netfilter/nflog: nflog-range does not truncate packets

On 06/17/2016 07:22 AM, Pablo Neira Ayuso wrote:
> On Wed, Jun 15, 2016 at 03:13:15PM +0000, Lubashev, Igor wrote:
>> Vish, Pablo,
>>
>> I wonder about the value of sending more data than a client is
>> willing to consume (setting aside the important fact that the client
>> code crashes due to the extra data).
>>
>> It seems that we should either drop the nflog-range parameter from
>> nflog altogether (and just use the len from the client) or allow
>> nflog-range to further *restrict* the number of bytes sent to the
>> client.
>>
>> The "further restrict" logic would make it easier to build iptables
>> rules that vary nflog-range based on some match conditions, so a
>> single client would get different packet length depending on what
>> rules matched.
> 
> Now I understand your usecase. Restricting the size based on match
> conditions sound reasonable to me.
> 
> Why don't you add a new userspace option, eg. --nflog-size, that
> specifies this "further restrict" logic?
> 
> What I'm proposing is:
> 
> 1) If --nflog-range is used, print a message telling: "--nflog-range
>    has never worked, ignoring this option."
> 
> 2) If --nflog-size is used, set the size in the structure that is
>    passed to the kernel, and apply this "further restrict" logic.
> 
> 3) Add the flag to the kernel that I suggested. This flag is only set
>    via --nflog-size.
> 
> Just to clarify: What I'm trying to avoid is breaking the thing for
> users that are using this --nflog-range (even if it doesn't work) and
> then change the behaviour for them.
> 
> With the new option, we really validate that the user is exactly
> asking for this "further restrict" logic that you need.
> 
> let me know, thanks.
> 

Sounds good to me, yes it will definitely change the behavior for users
who are using that parameter (whether intentional or not). I'm OK with
adding a new parameter instead of using --nflog-range. I will send a
patch with these changes.