netdev - Re: [devel-ipsec] [PATCH ipsec-next v10 1/3] xfrm: Add Direction to the SA in or out

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: <796e4bce-2e10-4aea-9d97-3b492616a4f8@6wind.com>
Date: Mon, 22 Apr 2024 11:54:33 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Sabrina Dubroca <sd@...asysnail.net>, Antony Antony <antony@...nome.org>
Cc: Antony Antony <antony.antony@...unet.com>,
 Steffen Klassert <steffen.klassert@...unet.com>,
 Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 devel@...ux-ipsec.org, Leon Romanovsky <leon@...nel.org>,
 Eyal Birger <eyal.birger@...il.com>
Subject: Re: [devel-ipsec] [PATCH ipsec-next v10 1/3] xfrm: Add Direction to
 the SA in or out

Le 22/04/2024 à 11:16, Sabrina Dubroca a écrit :
[snip]
>>>> And also this looks like a general cleanup up to me. I wonder how Steffen 
>>>> would add such a check for the upcoming PCPU attribute! Should that be 
>>>> prohibited DELSA or XFRM_MSG_FLUSHSA or DELSA?
>>>
>>> IMO, new attributes should be rejected in any handler that doesn't use
>>> them. That's not a general cleanup because it's a new attribute, and
>>> the goal is to allow us to decide later if we want to use that
>>> attribute in DELSA etc. Maybe in one year, we want to make DELSA able
>>> to match on SA_DIR. If we don't reject SA_DIR from DELSA now, we won't
>>> be able to do that. That's why I'm insisting on this.
>>
>> I have implemented a method to reject in v11, even though it is not my 
>> preference:) My argument xfrm has no precedence of limiting unused 
>> attributes in most types. We are not enforcing on all attributes such as 
>> upcoming PCPU.
> 
> I'll ask Steffen to enforce it there as well :)
> I think it's a mistake that old netlink APIs were too friendly to invalid input.
+1

This is an old problem in Netlink. There has been work during the last years to
be more strict about new attributes.

For example, see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56738f4608417