systemd — це набір демонов системного адміністрування
Нещодавно Розробники systemd мали дискусію в якому його поставили на стіл проблема зменшення залежностей бібліотеки libsystemd (бібліотека, яка відповідає за впровадження сервісів і взаємодію з systemd). Це тому, що в даний час існує певний стурбованість збільшенням залежностей третіх сторін у libsystemd, які не контролюються проектом і це збільшує поверхню атаки. Початок обговорення зазначає, що libsystemd завантажує кілька критичних бібліотек, таких як libzstd, liblz4 та libgcrypt, на додаток до liblzma та glibc. Це викликає серйозні проблеми з безпекою, особливо якщо ці сторонні бібліотеки скомпрометовані.
У Fedora, наприклад, понад 150 пакетів залежать від libsystemd, що збільшує складність і пов’язані з цим ризики. Пропозицію Для вирішення цього передбачає розділив libsystemd на кілька окремих бібліотек, кожна з яких відповідає за певний API. Це дозволить завантажувати сторонні залежності лише за необхідності, таким чином зменшуючи вплив потенційних уразливостей у бібліотеках, які безпосередньо не контролюються розробниками systemd.
Проте, розробники від systemd Вони стверджують, що це розділення було б проблематичним через взаємозв’язок драйверів, наявних у libsystemd. Вони вважають, що поділ буде трудомістким і може призвести до втрати ефективності або необхідності дублювати код, що буде протидіяти очікуваним перевагам безпеки.
Замість повного розлуки, libsystemd використав більш динамічний підхід шляхом динамічного завантаження бібліотеки liblzma, libzstd і liblz4, якщо це необхідно, за допомогою виклику dlopen(). Подібну зміну планується впровадити для libgcrypt у майбутніх випусках, щоб вирішити як питання безпеки, так і потреби ефективності коду та зручності обслуговування.
Я вважаю, що більшість із цих залежностей не є необхідними для реалізації основних функцій libsystemd, таких як згадані вище.
Ця проблема може означати поділ libsystemd на кілька бібліотек, які реалізують різні API, одна з яких, наприклад, libsystemd-core, залежатиме лише від libc, а інші більш спеціалізовані бібліотеки додадуть інші залежності. Крім того, якщо деякі залежності потрібні лише для певних системних служб, перемістіть залежності до цих служб.
Кінцевим ефектом цього має бути зменшення поверхні атаки та підвищення безпеки системи.
Під час обговорення Був один момент, який більшість розробників критикували, і вони згадують, що рішення неявно завантажувати сторонні бібліотеки за допомогою dlopen() у libsystemd створить додаткову роботу через додаткову складність діагностики та відсутність видимості посилань, вони також згадують, що це ускладнює ідентифікацію викликів API libsystemd, які підключаються до функцій зовнішньої бібліотеки, оскільки це неочевидно в коді. Цей новий спосіб завантаження, хоча він не змінює базову архітектуру, приховує зовнішні компоненти від супроводжувачів і користувачів.
Ленарт Поттерінг висловив свою незгоду з ідеєю поділу libsystemd на кілька бібліотек через ускладнення, які це призведе до спільного використання коду та підтримки стабільності API та простору імен. Розбиття libsystemd потребує відкриття всіх внутрішніх драйверів або статичної компіляції їх окремо в кожній бібліотеці, що може збільшити розмір через дублювання коду або ускладнити керування стабільністю та узгодженістю системи.
Замість поділу, стратегія завантаження зовнішніх бібліотек лише за необхідності вважається оптимальною, Крім того, щоб усунути додаткову складність діагностики, пропонується додати додаткові поля до файлів ELF з інформацією про завантажені динамічні залежності, що дозволить налагоджувачам обробляти цю інформацію та відображати її у виводі таких інструментів, як readelf. Це забезпечило б більшу прозорість і видимість динамічних залежностей, які використовує libsystemd, що спростило б діагностику та налагодження проблем, пов’язаних із динамічно завантажуваними зовнішніми бібліотеками.
Lenart рекомендований розробникам програм, які, замість прямого посилання на libsystemd для конкретної функціїобробник протоколу реалізований на рівні програми.
Це стратегія впровадження драйверів протоколу на прикладному рівні пропонує декілька перевагs:
- Зменшує залежність від libsystemd і уникає завантаження зовнішніх бібліотек, коли вони не потрібні.
- Забезпечує більшу гнучкість і контроль над конкретними функціями, які потрібні програмі.
- Спрощує діагностику та налагодження завдяки більш прямому контролю над виконанням певних функцій.
- Загалом цей підхід сприяє модульності та незалежності додатків, підвищуючи гнучкість і ефективність у розробці та обслуговуванні програмного забезпечення.
Якщо ви є цікаво дізнатися про це більше, Ви можете перевірити деталі У наступному посиланні.