Latest vulnerabilities for vendor "fedora project"

Obviously runc is similar to the pain points of dbus, where it is call anywhere with no ability to set defaults, but I think a combo of the below works pretty well. Container runtimes should still set reasonable defaults in the long run IMHO, but a combo of the below seems to work, but it will probably break kata containers etc... You can launch a vsock C2 container with runc as nobody with no issue and just a few env vars as an example.

I am not sure if there are any hypervisor tools that are in flatpack/snap/bwrap etc... but pretty much everything that is given userns and unlabeled may need a apparmor.d/local file for users actually using vsock for critical use cases.

This qualsys post from earlier this year applies: https://seclists.org/oss-sec/2025/q1/253

I am still trying to do more testing, but crun/runc/podman/buildah/chrome/chromium/firefox/etc. don't seem to break with a container only workload I have tested with the apparmor addition. Unfortunately putting it in globals would break things.

Kernel boot string ==================

Disables systemd sshd vsock listener, will not protect the L4 bridge.

The official way to disable vsock sshd is through a kernel command line parameters or system credentials logic. [systemd-ssh-generator]

systemd.sshauto=no

Mask systemd socket ===================

This will disable the systemd sshd vsock listener, but will not protect the L4 bridge.

sudo systemctl mask sshd-vsock.socket

Note:

If another unit explicitly wants "sshd-vsock.socket" it may be started.

AppArmor ========

This will remove access to the L4 bridge, which will also remove access to the systemd sshd vsock listener for targeted binaries.

Add the following to "/etc/apparmor.d/local/<filename>" for each high risk command.

audit deny network vsock,

SElinux =======

TODO

Seccomp =======

CRIs and sandbox commands should probably follow the methods containerd used when containerd blocked vsock [7442]

[7442] https://github.com/containerd/containerd/issues/7442

On Fri, Jan 2, 2026 at 4:14 PM <wish42offcl98 () posteo org> wrote: 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=AFINET # only AFINET RestrictAddressFamilies=~AFVSOCK # not AFVSOCK

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 afvsock socket in the global network namespace without any manual configuration. Obvious question: what manual configuration is required to kill that listener?

-- Jacob

First published (updated )

https://seclists.org/oss-sec/2026/q1/7