Hi,

Im trying to find a solution to a problem in the context of user space sandbox 
engineering on Linux and would appreciate any comments to guide me into the 
right direction in order to possible create a kernel patch that solves this 
problem:

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.

Thank you

- Stefan

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to