Isolating abstract sockets

When building userspace application sandboxes, one issue that does not seem trivial to solve is the isolation of abstract sockets.

While most IPC mechanism can be isolated by mechanisms like mount namespaces, abstract sockets are part of the network namespace.
It is possible to isolate abstract sockets by using a new network namespace, however, unprivileged processes can only create a new empty network namespace, which removes network access as well and makes this useless for network clients.

Same linux sandbox projects try to solve this by bridging the existing network interfaces into the new namespace or use something like slirp4netns to archive this, but this does not look like an ideal solution to this problem, especially since sandboxing should reduce the kernel attack surface without introducing more complexity.

Aside from containers using namespaces, sandbox implementations based on seccomp and landlock would also run into the same problem, since landlock only provides file system isolation and seccomp cannot filter the path argument and therefore it can only be used to block new unix domain socket connections completely.

Currently there does not seem to be any way to disable network namespaces in the kernel without also disabling unix domain sockets.

The question is how to solve the issue of abstract socket isolation in a clean and efficient way, possibly even without namespaces.
What would be the ideal way to implement a mechanism to disable abstract sockets either globally or even better, in the context of a process.
And would such a patch have a realistic chance to make it into the kernel?

- Stefan

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEjLwAv8xLYF1doyZLdIuckz2DLQMFAmOfafUACgkQdIuckz2D
LQPBvA/+N4WC1HWkoKk72tdHgduIFCoMS+xXF2H2aCGVUKQ5w5ZsZ3dXmHH1oT4T
smPOQf8yXHLZMriKx/neOcibX99G4Ta9OLXR37UOsz58psMoVXobJN33GuoDpWMx
+2yxVD2AeUNzoUJiRxQI7onDYN786Hdsd+tJP9KHFJ6Uwk3xo8rtpBjOPyaMEWRC
uGy9ljltt5khLAEojdNGyZN64mFj6GdTU6xecHHnN/lA/JYNWyTWIGIxVPp6nny6
doL1QJi/3h6D2sWWdaTiYzIErBmSbWn1OYO+hcEcyIe8HJMpJi+mm6zQ85YkhB1i
zvBc5H9i/7/N0V/9qzCCZ/9yaEimNzGDIAp4DCBDqoqt983EkQTMeqdNEU022L9r
rY9SUHnA+KagrYyk4979/Z9k12B7ldIT+oCqZ5SMQBElV6dVw/SJBq4Uepgc1Z++
wc7FQtz+nlaWib9c0z6GC4jc7BtGV+BHWeoLnTH0xj9nRym/r7HDXD7Xycbwwwne
8CUceP0cdVyd09+Ztd20OTRrMAzxAqacJi54zBm/HYYa0GEXsAP05+fZvC0/pHs1
0l3WHXoxUDNzfrPn7RDnTuTW9c9BJ51xcd9GrKXOb+HN8/eiLXHGZyuLuYp50DLj
A+3xUUIhMJpuRuW3EwQ1rf4S1y9mW01AES01H5rG7WocbeEwyT0=
=Rz8x
-----END PGP SIGNATURE-----