Re: Systemd vsock sshd

[Jacob Bachmeyer <jcb62281 () gmail com>]

On 12/29/25 13:53, Greg Dahlman wrote:
> 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.

I certainly agree that the systemd team's apparent "cavalier" attitude 
towards security (and sound architecture) makes lots of frustrations.  
(For example, the "katamari" architecture that made the xz-utils sshd 
backdoor possible is definitely a bad practice, although a distressingly 
common one not unique to systemd.)

To *really* set things off here, this vsock listener that crosses what 
is otherwise a security boundary *looks* like an attempt at a backdoor, 
although I believe it to be ignorance/negligence rather than malice.

> 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.

Does the systemd team understand that breaking container isolation may 
be completely unacceptable, to the point of "if you want secure 
containers, you must not use systemd" if they persist in setting up new 
unexpected listeners like this?

Maybe "zero config for VMs" is simply outside of the proper scope of a 
system service manager?  It could perhaps be an optional module.


-- Jacob