netdev - Re: [net-next 0/2] net: sched: cls-flower: add support for port-based fragment filtering

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, 29 May 2020 16:52:34 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     jbaron@...mai.com
Cc:     netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
        jiri@...nulli.us
Subject: Re: [net-next 0/2] net: sched: cls-flower: add support for
 port-based fragment filtering

From: Jason Baron <jbaron@...mai.com>
Date: Wed, 27 May 2020 16:25:28 -0400

> Port based allow rules must currently allow all fragments since the
> port number is not included in the 1rst fragment. We want to restrict
> allowing all fragments by inclucding the port number in the 1rst
> fragments.
> 
> For example, we can now allow fragments for only port 80 via:
> 
> # tc filter add dev $DEVICE parent ffff: priority 1 protocol ipv4 flower
>   ip_proto tcp dst_port 80 action pass
> # tc filter add dev $DEVICE parent ffff: priority 2 protocol ipv4 flower
>   ip_flags frag/nofirstfrag action pass
> 
> The first patch includes ports for 1rst fragments.
> The second patch adds test cases, demonstrating the new behavior.

But this is only going to drop the first frag right?

Unless there is logic to toss the rest of the frags this seems
extremely hackish as best.

I don't want to apply this as-is, it's a short sighted design
as far as I am concerned.