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

Date:	Fri, 17 Jun 2016 13:22:19 +0200
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	"Lubashev, Igor" <ilubashe@...mai.com>
Cc:	"Pai, Vishwanath" <vpai@...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 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.