[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <937f78c2-45fc-4062-8941-f6f419004318@gmail.com>
Date: Tue, 30 Dec 2025 00:33:47 -0600
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, Greg Dahlman <dahlman@...il.com>
Subject: Re: Systemd vsock sshd
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
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.
