netdev - Re: [PATCH net-next 2/5] net: sched: em_ipt: set the family based on the protocol when matching

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: <55E75AF3-EEFA-4AD3-B34D-470E16071DAC@cumulusnetworks.com>
Date:   Wed, 26 Jun 2019 19:38:41 +0300
From:   nikolay@...ulusnetworks.com
To:     Eyal Birger <eyal.birger@...il.com>
CC:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        pablo@...filter.org, xiyou.wangcong@...il.com, davem@...emloft.net,
        jiri@...nulli.us, jhs@...atatu.com
Subject: Re: [PATCH net-next 2/5] net: sched: em_ipt: set the family based on the protocol when matching

On 26 June 2019 19:22:54 EEST, Eyal Birger <eyal.birger@...il.com> wrote:
>On Wed, 26 Jun 2019 16:45:28 +0300
>Nikolay Aleksandrov <nikolay@...ulusnetworks.com> wrote:
>
>> On 26/06/2019 16:33, Eyal Birger wrote:
>> > Hi Nikolay,
>> >    
>> > On Wed, 26 Jun 2019 14:58:52 +0300
>> > Nikolay Aleksandrov <nikolay@...ulusnetworks.com> wrote:
>> >   
>> >> Set the family based on the protocol otherwise protocol-neutral
>> >> matches will have wrong information (e.g. NFPROTO_UNSPEC). In
>> >> preparation for using NFPROTO_UNSPEC xt matches.
>> >>
>> >> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>> >> ---
>> >>  net/sched/em_ipt.c | 4 +++-
>> >>  1 file changed, 3 insertions(+), 1 deletion(-)
>> >>
>...
>> >> -	nf_hook_state_init(&state, im->hook, im->match->family,
>> >> +	nf_hook_state_init(&state, im->hook, state.pf,
>> >>  			   indev ?: skb->dev, skb->dev, NULL,
>> >> em->net, NULL); 
>> >>  	acpar.match = im->match;  
>> > 
>> > I think this change is incompatible with current behavior.
>> > 
>> > Consider the 'policy' match which matches the packet's xfrm state
>> > (sec_path) with the provided user space parameters. The sec_path
>> > includes information about the encapsulating packet's parameters
>> > whereas the current skb points to the encapsulated packet, and the
>> > match is done on the encapsulating packet's info.
>> > 
>> > So if you have an IPv6 packet encapsulated within an IPv4 packet,
>> > the match parameters should be done using IPv4 parameters, not
>IPv6.
>> > 
>> > Maybe use the packet's family only if the match family is UNSPEC?
>> > 
>> > Eyal.
>> >   
>> 
>> Hi Eyal,
>> I see your point, I was wondering about the xfrm cases. :)
>> In such case I think we can simplify the set and do it only on UNSPEC
>> matches as you suggest.
>> 
>> Maybe we should enforce the tc protocol based on the user-specified
>> nfproto at least from iproute2 otherwise people can add mismatching
>> rules (e.g. nfproto == v6, tc proto == v4).
>> 
>Hi Nik,
>
>I think for iproute2 the issue is the same. For encapsulated IPv6 in
>IPv4 for example, tc proto will be IPv6 (tc sees the encapsulated
>packet after decryption) whereas nfproto will be IPv4 (policy match is
>done on the encapsulating state metadata which is IPv4).
>
>I think the part missing in iproute2 is the ability to specify
>NFPROTO_UNSPEC.
>
>Thanks,
>Eyal

Right, I answered too quickly, it makes sense to mix them for xt policy.
I also plan to add support for clsact, it should be trivial and iproute2-only
change.
  
Thanks, 
  Nik