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
