oss-sec mailing list archives
Re: Systemd vsock sshd
From: Solar Designer <solar () openwall com>
Date: Thu, 19 Feb 2026 05:15:19 +0100
On Tue, Feb 03, 2026 at 04:46:56PM +0100, Bastian Blank wrote:
On Sat, Dec 27, 2025 at 08:46:49PM -0700, Greg Dahlman wrote:**vsock exists in the global namespace** - Unlike "af_inet" sockets, vsock connections are not bound to a particular network namespace. By default they are visible to every namespace on the host.Every address family in Linux needs to implement it's own namespace handling. In 2007, all existing address families got a check to only allow the inital network namespace. af_vsock is newer and never got this check. Every point after the first one is just a result, not a cause. So a fix would be something like that (untested, no time right now): --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -2553,6 +2553,9 @@ static int vsock_create(struct net *net, struct socket *sock, if (protocol && protocol != PF_VSOCK) return -EPROTONOSUPPORT; + if (!net_eq(net, &init_net)) + return -EAFNOSUPPORT; + switch (sock->type) { case SOCK_DGRAM: sock->ops = &vsock_dgram_ops;
Brad Spengler pointed me at this Linux merge commit (it's not in 6.19, should get into 6.20): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=099ca4121ea747acc8a0d36852f2f477943f306d commit 099ca4121ea747acc8a0d36852f2f477943f306d Merge: 3eef6c061f97 b3b7b33264c6 Author: Paolo Abeni <pabeni () redhat com> Date: Tue Jan 27 10:45:40 2026 +0100 Merge branch 'vsock-add-namespace-support-to-vhost-vsock-and-loopback' Bobby Eshleman says: ==================== vsock: add namespace support to vhost-vsock and loopback This series adds namespace support to vhost-vsock and loopback. It does not add namespaces to any of the other guest transports (virtio-vsock, hyperv, or vmci). The current revision supports two modes: local and global. Local mode is complete isolation of namespaces, while global mode is complete sharing between namespaces of CIDs (the original behavior). The mode is set using the parent namespace's /proc/sys/net/vsock/child_ns_mode and inherited when a new namespace is created. The mode of the current namespace can be queried by reading /proc/sys/net/vsock/ns_mode. The mode can not change after the namespace has been created. Modes are per-netns. This allows a system to configure namespaces independently (some may share CIDs, others are completely isolated). This also supports future possible mixed use cases, where there may be namespaces in global mode spinning up VMs while there are mixed mode namespaces that provide services to the VMs, but are not allowed to allocate from the global CID pool (this mode is not implemented in this series). Additionally, added tests for the new namespace features: tools/testing/selftests/vsock/vmtest.sh 1..25 ok 1 vm_server_host_client ok 2 vm_client_host_server ok 3 vm_loopback ok 4 ns_host_vsock_ns_mode_ok ok 5 ns_host_vsock_child_ns_mode_ok ok 6 ns_global_same_cid_fails ok 7 ns_local_same_cid_ok ok 8 ns_global_local_same_cid_ok ok 9 ns_local_global_same_cid_ok ok 10 ns_diff_global_host_connect_to_global_vm_ok ok 11 ns_diff_global_host_connect_to_local_vm_fails ok 12 ns_diff_global_vm_connect_to_global_host_ok ok 13 ns_diff_global_vm_connect_to_local_host_fails ok 14 ns_diff_local_host_connect_to_local_vm_fails ok 15 ns_diff_local_vm_connect_to_local_host_fails ok 16 ns_diff_global_to_local_loopback_local_fails ok 17 ns_diff_local_to_global_loopback_fails ok 18 ns_diff_local_to_local_loopback_fails ok 19 ns_diff_global_to_global_loopback_ok ok 20 ns_same_local_loopback_ok ok 21 ns_same_local_host_connect_to_local_vm_ok ok 22 ns_same_local_vm_connect_to_local_host_ok ok 23 ns_delete_vm_ok ok 24 ns_delete_host_ok ok 25 ns_delete_both_ok SUMMARY: PASS=25 SKIP=0 FAIL=0 Thanks again for everyone's help and reviews! Suggested-by: Sargun Dhillon <sargun () sargun me> Signed-off-by: Bobby Eshleman <bobbyeshleman () gmail com> v15: https://lore.kernel.org/r/20260116-vsock-vmtest-v15-0-bbfd1a668548 () meta com v14: https://lore.kernel.org/r/20260112-vsock-vmtest-v14-0-a5c332db3e2b () meta com v13: https://lore.kernel.org/all/20251223-vsock-vmtest-v13-0-9d6db8e7c80b () meta com/ v12: https://lore.kernel.org/r/20251126-vsock-vmtest-v12-0-257ee21cd5de () meta com v11: https://lore.kernel.org/r/20251120-vsock-vmtest-v11-0-55cbc80249a7 () meta com v10: https://lore.kernel.org/r/20251117-vsock-vmtest-v10-0-df08f165bf3e () meta com v9: https://lore.kernel.org/all/20251111-vsock-vmtest-v9-0-852787a37bed () meta com v8: https://lore.kernel.org/r/20251023-vsock-vmtest-v8-0-dea984d02bb0 () meta com v7: https://lore.kernel.org/r/20251021-vsock-vmtest-v7-0-0661b7b6f081 () meta com v6: https://lore.kernel.org/r/20250916-vsock-vmtest-v6-0-064d2eb0c89d () meta com v5: https://lore.kernel.org/r/20250827-vsock-vmtest-v5-0-0ba580bede5b () meta com v4: https://lore.kernel.org/r/20250805-vsock-vmtest-v4-0-059ec51ab111 () meta com v2: https://lore.kernel.org/kvm/20250312-vsock-netns-v2-0-84bffa1aa97a () gmail com v1: https://lore.kernel.org/r/20200116172428.311437-1-sgarzare () redhat com ==================== Link: https://patch.msgid.link/20260121-vsock-vmtest-v16-0-2859a7512097 () meta com Signed-off-by: Paolo Abeni <pabeni () redhat com> Brad's comments on it are: https://x.com/spendergrsec/status/2021929584384438428 Feb 12 Looks like the defaults (global for both ns_mode/child_ns_mode) keep everything working the same as currently, doesn't seem like it'd restrict anything under unpriv userns as nothing stops changing child_ns_mode back to global after first setting it to local. Feb 14 Same things I noticed: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=36e838630c111a510f47e49d559bd26aba7d9a1b https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6a997f38bdf822d4c5cc10b445ff1cb26872580a Feb 16 The design of this whole thing actually seems to me entirely broken and useless, especially for something that took 7 years to land. If you want any kind of reasonable legit use of vsock with this, you're forced into global/global mode that allows all the unreasonable things. The local mode also forcing local id allocation is the main aspect making it unusable (and unfixable later, unless I'm missing something). If at least the id allocation were global, then you could implement some reasonable directional/cap-based policies... but not when you can't even see what you should be able to connect to (especially so when the same id can be reused by local mode containers). The referenced netdev commits made on Feb 13 fix issues with the initially merged implementation, and aren't yet in Linus' tree.
But I have a question: why do you name sshd, while every AF_VSOCK listener is affected?
I assume you're asking Greg - CC'ing. Alexander
Current thread:
- Re: Systemd vsock sshd wish42offcl98 (Jan 02)
- Re: Systemd vsock sshd Greg Dahlman (Jan 02)
- Re: Systemd vsock sshd Carlos Rodriguez-Fernandez (Jan 02)
- <Possible follow-ups>
- Re: Systemd vsock sshd Solar Designer (Jan 08)
- Re: Systemd vsock sshd Greg Dahlman (Jan 08)
- Re: Systemd vsock sshd Bastian Blank (Feb 03)
- Re: Systemd vsock sshd Solar Designer (Feb 18)
- Re: Systemd vsock sshd Greg Dahlman (Jan 02)
