[devel] devel-static

[Vitaly Lipatov]

Andrey Savchenko писал 25.8.21 22:14:
> On Wed, 25 Aug 2021 20:14:41 +0300 Dmitry V. Levin wrote:
>> On Wed, Aug 25, 2021 at 12:18:40PM +0300, Andrey Savchenko wrote:
...
>> > Динамическая линковка лишь создаёт иллюзию безопасности за счёт
>> > исправления проблемы в одной библиотеке сразу для всех. Но проблема
>> > может быть в хедерах, а C++ библиотеки всё больше переходят
>> > в хедеры. В итоге может получится, что CVE исправлен, библиотека
>> > обновлена без изменения ABI, а непересобранные приложения всё ещё
>> > уязвимы.
>> 
>> А безопаснее всего публиковать только исходники, и пусть пользователи
>> сами пересобирают, как сочтут нужным, правда же?
> 
> На этот вопрос нельзя однозначно ответить, поскольку в таком
> случае задача обеспечения безопасности во многом перекладывается на
> пользователей и ответ зависит от их квалификации. Так вернёмся к
> обсуждению DSO vs static в бинарном дистрибутиве общего назначения.
> 
> 1) Безопасность.
> 
> Выше я привёл пример, когда DSO лишь маскирует проблему
> безопасности, но не решает её. В случае со static очевидно, что
> пересобирать нужно всех потребителей (при необходимости рекурсивно).
> Так что относительно просто реализовать механизм контроля
> гарантированного исправления ошибок и уязвимостей среди
> прямых и косвенных пользователей библиотеки.
> 
> В случае с DSO может возникнуть крайне опасная ситуация скрытого
> наличия уязвимости, когда CVE в библиотеке исправлен, по
> setversions с клиентами всё хорошо, мы успешно заявили об
> исправлении данной CVE в дистрибутиве, а в реальности уязвимость
> кое-где осталась.
> 
> Самым простым решением данной проблемы будет безусловная пересборка
> всех зависимостей, так же, как и со static — но в таком случае
> никаких преимуществ у DSO не остаётся.
> 
> Можно попробовать отслеживать, были ли изменения хедеров
> и пересобирать безусловно только в таком случае — но это более
> сложный и в то же время всё ещё грубый путь решения задачи, т.к. не
> всякое изменение в хедере ведёт к изменению бинарного кода
> в клиенте.
Я бы хотел добавить только, что
в реальной жизни эта проблема решается проще — при исправлении CVE 
проект выпускает новую версию библиотеки, и если вдруг уязвимость 
требует пересборки клиентов (из-за её исправления в заголовочных 
файлах), то об этом сообщат пользователям библиотеки (в описании 
релиза).
Также, как я понимаю, достаточно сложно создать уязвимость именно в том 
коде, который генерируется при сборке приложения, а не библиотеки. Разве 
известны такие случаи?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team