On Fri, Mar 28, 2025 at 06:03:19PM +0100, Stefano Garzarella wrote: > CCing Daniel > > On Wed, Mar 12, 2025 at 01:59:34PM -0700, Bobby Eshleman wrote: > > Picking up Stefano's v1 [1], this series adds netns support to > > vhost-vsock. Unlike v1, this series does not address guest-to-host (g2h) > > namespaces, defering that for future implementation and discussion. > > > > Any vsock created with /dev/vhost-vsock is a global vsock, accessible > > from any namespace. Any vsock created with /dev/vhost-vsock-netns is a > > "scoped" vsock, accessible only to sockets in its namespace. If a global > > vsock or scoped vsock share the same CID, the scoped vsock takes > > precedence. > > > > If a socket in a namespace connects with a global vsock, the CID becomes > > unavailable to any VMM in that namespace when creating new vsocks. If > > disconnected, the CID becomes available again. > > I was talking about this feature with Daniel and he pointed out something > interesting (Daniel please feel free to correct me): > > If we have a process in the host that does a listen(AF_VSOCK) in a > namespace, can this receive connections from guests connected to > /dev/vhost-vsock in any namespace? > > Should we provide something (e.g. sysctl/sysfs entry) to disable > this behaviour, preventing a process in a namespace from receiving > connections from the global vsock address space (i.e. /dev/vhost-vsock > VMs)? > > I understand that by default maybe we should allow this behaviour in order > to not break current applications, but in some cases the user may want to > isolate sockets in a namespace also from being accessed by VMs running in > the global vsock address space. >
Adding this strict namespace mode makes sense to me, and I think the sysctl/sysfs approach works well to minimize application changes. The approach we were taking was to only allow /dev/vhost-vsock-netns (no global /dev/vhost-vsock mixed in on the system), but adding the explicit system-wide option I think improves the overall security posture of g2h connections. > Indeed in this series we have talked mostly about the host -> guest path (as > the direction of the connection), but little about the guest -> host path, > maybe we should explain it better in the cover/commit > descriptions/documentation. > Sounds good! Best, Bobby
