[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM=PXV705V7Su6kwyKAipXtAqi+DU644Qxv_4LsqC=FVG5bg0Q@mail.gmail.com>
Date: Mon, 29 Dec 2025 11:16:48 -0700
From: Greg Dahlman <dahlman@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Systemd vsock sshd
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 <
benjamin.mcmahon@...pros.com> 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 <jcb62281@...il.com>
> Sent: Sunday, December 28, 2025 10:11 PM
> To: oss-security@...ts.openwall.com <oss-security@...ts.openwall.com>;
> Greg Dahlman <dahlman@...il.com>
> Subject: Re: [oss-security] Systemd vsock sshd
>
>
> [You don't often get email from jcb62281@...il.com. 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
>
>
>
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
