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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <85546d35-c7bd-49bf-b0c3-9677bde25859@I-love.SAKURA.ne.jp>
Date: Mon, 9 Feb 2026 19:02:47 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Steffen Klassert <steffen.klassert@...unet.com>,
        Paul Moore <paul@...l-moore.com>, SELinux <selinux@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>
Cc: 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 2026/02/09 18:25, Steffen Klassert wrote:
> 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.

Unfortunately, unregistering is not always triggered by a user's request. ;-)

For example, we don't check permission for unmount when a mount is deleted
due to teardown of a mount namespace. I wonder why you want to check permission
for unregistering a net_device when triggered by a teardown path.

> 
> 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.

Is replacing the NETDEV_UNREGISTER net_device with the blackhole_netdev applicable
( https://elixir.bootlin.com/linux/v6.19-rc5/source/net/xfrm/xfrm_policy.c#L3948 ) ?
If no, there is no choice but break SELinux's expectation.