Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()

[Steffen Klassert <steffen.klassert@secunet.com>]

On Mon, Feb 09, 2026 at 07:02:47PM +0900, Tetsuo Handa wrote:
> 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. ;-)

As far as I remember, a security context is not always tied to a
user request. It can also be attached to system tasks or objects.

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

I just try to find out what's the right thing to do here.
If a policy goes away, packets that match this policy will
find another path through the network stack. As best, they
are dropped somewhere, but they can also leave on some other
device without encryption. A LSM that implements xfrm hooks
must be able to check the permission to delete the xfrm policy
or state.

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

That could be an option to not accidentally send out
unencrypted packets. But finding the right place for
these checks would be preferable IMO.