Re: Systemd vsock sshd

[wish42offcl98 () posteo org]

I do not use Fedora, but I checked the update repo for f42.
Neither openssh ¹, nor systemd ² have been updated for Fedora 42 in the 
last few weeks. Thus I have to guess that your method to setup/test the 
VM was different.
Just in case, I have masked the vsock socket on all of my instances (no 
VMs though) and I will check on occasions if masking disappears.

Nonetheless, I dug deeper into systemd and checked their source code ³.
systemd-vmspawn uses another service:
systemd.unit-dropin.sshd-vsock@.service ⁴
And there is also sshd-vsock@.service ⁵ which might require another 
masking - same for sshd-unix-local@.service ⁶.

Since I do not use VMs, it was rather an addition for this list, thus I 
won't dig deeper for now.
busctl is unknown to me (yet).
The "RestrictAddressFamilies" option for services might be another idea 
to restrict sshd - but I don't know if it affects the unix-socket/vsock 
sockets generated by systemd - and whether this also influences access 
to local sockets (e.g. to control systemd itself).

I haven't understood the L4 bridge issue completely yet, so I would need 
to read more into it and test it.
My guess on the L4 bridge problem:
- Exposed vsocks are in global namespace.
- VMs with enabled vsock feature (on hypervisor and inside VM) expose 
their services.
- Containers (with unmitigated container runtimes) run on the hypervisor 
(not within VMs) are able to access the vsocks of VMs.
That's a short description of my current understanding to it.



1 https://bodhi.fedoraproject.org/updates/FEDORA-2025-ad76584c00
2 https://bodhi.fedoraproject.org/updates/FEDORA-2025-61132a053f
3 https://github.com/systemd/systemd/
4 
https://github.com/systemd/systemd/blob/v259-stable/src/vmspawn/vmspawn.c#L2654
5 
https://github.com/systemd/systemd/blob/v259-stable/src/ssh-generator/ssh-generator.c#L228
6 
https://github.com/systemd/systemd/blob/v259-stable/src/ssh-generator/ssh-generator.c#L265


On 12/30/25 21:44, Greg Dahlman wrote:
> Thanks for the reply Alex,
>
> I didn't include that option because I ran into an issue that I couldn't
> find the root cause for. Specifically on Fedora, a `dnf upgrade` resulted
> in the mask disappearing.  I could find some complaints with Fedora version
> upgrades, but couldn't find anything on package upgrade.
>
> As I don't have access to the RedHat support portal I decided to exclude it
> out of caution.
>
> It looked like there was nothing in /usr/lib/systemd/system-preset for
> sshd-vsock.socket that I found, and those should respect the mask for
> sshd-vsock.socket and wouldn't remove the
>   /etc/systemd/system/sshd-vsock.socket symlink as I understand it.
>
> I think that because it doesn't show up in `busctl --activatable`, and no
> packages I can find "Wants" sshd-vsock.socket explicitly that would
> probably work.
>
> I just tried a fresh install of Fedora Linux 42 workstation and didn't
> experience the unintended unmasking with a dnf upgrade. That was reliable a
> few weeks ago. Maybe I just was unlucky with a package that was fixed?
>
> Either way I think it is an option for people who use configuration
> management tools that can periodically check sshd-vsock.socket is still
> disabled.
>
> Also for normal *systemd* services that need isolation from the vsock
> bridge you can use:
>
> RestrictAddressFamilies=none # disable all af families
> RestrictAddressFamilies=AF_INET # only AF_INET
> RestrictAddressFamilies=~AF_VSOCK # not AF_VSOCK
>
>
> The L4 bridge problem will be harder for projects that use CRI's that are
> not containerd like the k8s/podman/crun/runc.
>
> If anyone on here is involved with them, or sandboxing tools
> like bubblewrap etc... Filtering address family 40 will still be required
> by default to have any real intra-container/pod/process network isolation
> on a node.
>
> Thanks,
>
> Greg
>
> On Tue, Dec 30, 2025 at 12:12 PM <wish42offcl98 () posteo org> wrote:
>
> > I have searched for that - instead of blacklisting the vsock module, I
> > did myself two measures:
> > - systemctl mask --now sshd-unix-local.socket
> > to kill and mask the sshd unix socket created by that generator,
> > - systemctl mask sshd-vsock.socket
> > to mask the sshd vsock created by that generator (use --now if the
> > socket has started or use systemctl stop... ).
> >
> > Though, vsock untested but I found that source mentioning that socket.
> > https://linux-audit.com/system-administration/commands/systemd-analyze/
> > Masking the sockets should stop them from starting again.
> >
> > The vsock kernel module should not be blacklisted if some hypervisor
> > features are required:
> > https://libvirt.org/ssh-proxy.html
> > https://wiki.qemu.org/Features/VirtioVsock
> >
> > Greetings
> > Alex
> >
> >
> > On 12/29/25 05:11, Jacob Bachmeyer wrote:
> > > 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