[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM=PXV4yADSZ2udrWhiWNocroCj4ceefd2V5ANOUYYcTF_+SHA@mail.gmail.com>
Date: Mon, 29 Dec 2025 12:53:45 -0700
From: Greg Dahlman <dahlman@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Systemd vsock sshd
I did reach out to the systemd team, while I was working with the kernel
security team and I encouraged others to do so if they think it will be
productive.
There are sensitivities and frustrations that span all groups that make
that conversation difficult, but I think someone with an established trust
with the project could make forward progress.
That said, disabling this bridge will impact systemd's attempt to
enable zero config for VMs. The container ecosystem as a whole hasn't
exactly demonstrated that they will reciprocate. In a perfect world the
container runtimes would protect their use case from the remainder of the
shared kernel by default, unfortunately that is not what we have today.
I think if people with existing relationships reached out to the systemd
team there could be a discussion on this specific issue, but it is
completely understandable that when one use case appears to block your
projects use case repeatedly, your willingness to make sacrifices will
diminish over time.
I would just ask that people who reach out to the team take the above into
account.
Greg
On Mon, Dec 29, 2025 at 11:44 AM Pat Gunn <pgunn01@...il.com> wrote:
> 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 <dahlman@...il.com> 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 <
> > 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.
