netdev - Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx

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: <aYmoDwO-YXrc4W1c@secunet.com>
Date: Mon, 9 Feb 2026 10:25:35 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
CC: Paul Moore <paul@...l-moore.com>, SELinux <selinux@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>, Herbert Xu
	<herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Network Development
	<netdev@...r.kernel.org>
Subject: Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()

On Wed, Feb 04, 2026 at 10:57:30PM +0900, Tetsuo Handa wrote:
> On 2026/02/04 19:15, Tetsuo Handa wrote:
> > On 2026/02/04 7:40, Paul Moore wrote:
> >>         This is not an unusual request for such a proposed change, and
> >> is something that I would expect a LSM maintainer to do without much
> >> hesitation.  If you are unwilling to investigate this, can you explain
> >> why?
> > 
> > Because I'm not familiar with how XFRM works; I'm not a user of LSM XFRM hooks.
> > 
> > I can't judge whether the current code is COMPREHENSIVELY GATING;
> > I can't imagine what the state you call COMPREHENSIVELY GATING is.
> 
> Steffen Klassert worried that killing xfrm_dev_state_flush_secctx_check() and
> xfrm_dev_policy_flush_secctx_check() might violate a LSM policy and you agreed
> ( https://lkml.kernel.org/r/CAHC9VhQ54LRD7k_x6tUju2kPVBEHcdgBh46_hBN8btG0vhfy_w@mail.gmail.com ),
> but the reality is that nobody in the world has enforced an LSM policy for almost 9 years
> that makes xfrm_dev_{state,policy}_flush() no-op. That is, xfrm_dev_state_flush_secctx_check()
> and xfrm_dev_policy_flush_secctx_check() had been effectively unused.
> 
> Killing xfrm_dev_state_flush_secctx_check() and xfrm_dev_policy_flush_secctx_check()
> increases "system's stability" without sacrificing "authorization".
> 
> It is up to SELinux developers to discuss what actions to take as a compensation for
> killing xfrm_dev_state_flush_secctx_check() and xfrm_dev_policy_flush_secctx_check().
> The compensation might be to add LSM hooks to immediately before the point of no return.

The problem is that, with adding IPsec offloads to netdevices, security
critical resources came into the netdevices. Someone who has no
capabilities to delete xfrm states or xfrm policies should not be able
to unregister the netdevice if xfrm states or xfrm policies are
offloaded. Unfortunately, unregistering can't be canceled at this stage
anymore. So I think we need some netdevice unregistration hook for
the LSM subsystem so it can check for xfrm states or xfrm policies
and refuse the unregistration before we actually start to remove
the device.

The same happened btw. when xfrm was made per network namespace.
Here we just leak the xfrm states and xfrm policies if some
LSM refuses to remove them.

I guess we need a solution for both cases.