On Sa, 30.03.24 13:18, Gordon Messmer (gordon.messmer(a)gmail.com) wrote:
On 2024-03-30 02:37, Richard W.M. Jones wrote:
> (3) We should have a "security path", like "critical path".
>
> sshd is linked to a lot of libraries:
I really don't want to start a systemd thread, but... the xz, lz4, and zstd
libraries are pulled in by libsystemd, merely so that sshd can call
"sd_notify"
(
https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-s...),
which raises a couple of questions.
The first one that comes to mind is: Is the increased attack surface
incurred by linking to these additional libraries worth the value provided
by calling "sd_notify", or should that patch be dropped to improve sshd
security?
As discussed elsewhere: these deps are now dlopen() in systemd git
main. So they are basically gone, unless you actually use one of the
API calls that need the code.
The second is: Is libsystemd too large? I could very easily be
misreading
it, but it looks like at least some of src/libsystemd/sd-journal is used by
journald, including the compression bits. Do those really belong in
libsystemd?
There are various programs that use sd-journal to read journal
files. It's after all *the* place to you get your logs from these
days. And journal files can be compressed. We only use one compressor
when writing, but we have changed the compression library
(i.e. nowadays use zstd), and need to provide read
compatibility. Hence the other compression libs.
If they need to be shared components, could the journald
components be split out to reduce the size of libsystemd? (That is, to
avoid linking to the compression libs?)
This creates many other problems. For an explanation see the various
comments here:
https://github.com/systemd/systemd/issues/32028
Also, I don't think we should get hung up too much on the libsystemd
thing. I know people like to hit on systemd, but the attacker could
have used various other vehicle libs for their goal, too. I mean, sshd
uses PAM, and that pull in variety of things through its modules, and
that's just very hard to properly review even when one just focusses
on the default PAM config on Fedora.
Lennart
--
Lennart Poettering, Berlin