Would it be productive to reach out to the systemd maintainers to ask them to have their software not do this and release a patch? This probably would break some software that depends on the bad behaviour, but the fallout from managing this may encourage them to think a little bit about security and good software design in the future (tempted to add several paragraphs of snark to this, but will omit).
On Mon, 29 Dec 2025 at 13:33, Greg Dahlman <[email protected]> wrote: > Thank you Benjamin, > > Yes, the kernel boot string is the only way to currently mitigate the > listener. The L4 loopback issue, which is a trivial extension, can only be > mitigated by patching the kernel the way chromeOS did or reliably filtering > af address family 40 (af_vsock) at the CRI, bubblewrap, etc… level with > seccomp. > > The current state of apparmor and SElinux will make filtering at that level > opportunistic at best. It should also be noted that adding the kernel boot > string will be a breaking change for users who expect the hypervisor to > have ssh access to guests for administrative purposes. The trusted > hypervisor, untrusted guest assumptions that vsock was based on are an > important use case. > > For the listener specifically, a fix that would support both use cases > would require modifying `systemd/systemd/src/ssh-generator/ssh-generator.c > < > https://github.com/systemd/systemd/blob/f76f0f99354b0485e3e13c2608bc26f969312687/src/ssh-generator/ssh-generator.c > >` > to allow control of the socket-activated sshd listener through a > configuration file. > > The ssh-generator is just emitting typical systemd socket activation unit > files, and I think the path that would be most productive if the > relevant stakeholders were willing or if the distro's were willing to to > patch the upstream source. > > As af_vsock is a convenient socket() like interface, there are still some > use cases/projects that will break, but the above is the path forward that > seems to minimise the impact. > > Greg > > On Mon, Dec 29, 2025 at 10:17 AM Benjamin McMahon < > [email protected]> wrote: > > > To prevent the vsock-based sshd from auto-spawning, see > > > https://www.freedesktop.org/software/systemd/man/devel/systemd-ssh-generator.html > > > > In short: `systemd.ssh_auto=no` is the kernel-command-line setting which > > persists after reboots. > > > > ~Benjamin > > > > ________________________________________ > > From: Jacob Bachmeyer <[email protected]> > > Sent: Sunday, December 28, 2025 10:11 PM > > To: [email protected] <[email protected]>; > > Greg Dahlman <[email protected]> > > Subject: Re: [oss-security] Systemd vsock sshd > > > > > > [You don't often get email from [email protected]. Learn why this is > > important at https://aka.ms/LearnAboutSenderIdentification ] > > > > On 12/27/25 21:46, Greg Dahlman wrote: > > > [...] > > > > > > **Systemd v256 change** - When the *openssh-server* package is > > > installed on a VM with vsock support, systemd now automatically > > > starts an *sshd* instance that listens on the **af_vsock** socket in > > > the **global network namespace** without any manual configuration. > > > > Obvious question: what manual configuration is required to kill that > > listener? > > > > > > -- Jacob > > > > > > > > >
