[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM=PXV5UD8cajTnkcemP+cymphiLe7nRQYBBGAimz+S7svYVxA@mail.gmail.com>
Date: Tue, 30 Dec 2025 13:44:43 -0700
From: Greg Dahlman <dahlman@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Systemd vsock sshd
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@...teo.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
>
>
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.
