On Sa, 30.03.24 13:18, Gordon Messmer (gordon.messmer@xxxxxxxxx) 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-systemd.patch), > 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 -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
