Уязвимости в лицензиях СПО (Андрей Савченко, OSSDEVCONF-2018) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) (Новая страница: «;{{SpeakerInfo}}: {{Speaker|Андрей Савченко}} <blockquote> Лицензии на программное обеспечение можно рассм…») |
StasFomin (обсуждение | вклад) |
||
;{{SpeakerInfo}}: {{Speaker|Андрей Савченко}} <blockquote> Лицензии на программное обеспечение можно рассматривать как программы. Как и любые программы, лицензии не идеальны и содержат уязвимости, которые эксплуатируются злоумышленниками с целью ограничения прав и свобод пользователей и разработчиков. Ситуация осложняется тем, что из-за недоработок в лицензиях можно формально их выполнить, но нарушить суть и основную идею. В данной работе будет рассмотрено как это происходит и что можно попытаться с подобными явлениями сделать. </blockquote> {{VideoSection}} {{vimeoembed|287829368|800|450}} <!-- {{youtubelink|}} --> {{SlidesSection}} [[File:Уязвимости в лицензиях СПО (Андрей Савченко, OSSDEVCONF-2018).pdf|left|page=-|300px]] {{----}} == Thesis == |
Версия 20:19, 9 октября 2018
- Докладчик
- Андрей Савченко
Лицензии на программное обеспечение можно рассматривать как программы.
Как и любые программы, лицензии не идеальны и содержат уязвимости, которые эксплуатируются злоумышленниками с целью ограничения прав и свобод пользователей и разработчиков. Ситуация осложняется тем, что из-за недоработок в лицензиях можно формально их выполнить, но нарушить суть и основную идею.
В данной работе будет рассмотрено как это происходит и что можно попытаться с подобными явлениями сделать.
Содержание
Видео
Презентация
Thesis
Введение
По мере роста сложности лицензий на программное обеспечение (ПО) они сами приобретают признаки программы, поскольку они описывают набор правил и алгоритмов по использованию ПО. Разумеется, это верно как для проприетарных, так и для свободных лицензий, но в данной работе внимание будет уделено лицензиям свободного ПО (СПО).
Как и любое ПО, лицензии не идеальны, они содержат как архитектурные ошибки, так и проблемы реализации, поскольку невозможно предусмотреть все краевые случаи и особые ситуации при разработке лицензии.
Текущее состояние
Философия СПО определяет четыре свободы пользователей: свободу на выполнение, копирование, изменение и распространение ПО.
Ярким примером нарушения этих базовых свобод при формальном соблюдении свободной лицензии является проблема тивоизации. В GPLv2 содержится уязвимость, позволяющая производителям на аппаратном уровне блокировать свободу пользователя обновлять ПО на устройстве, оставляя при этом такую возможность для производителя; тем самым возможность пользователя использовать модифицированное ПО и все связанные с этим свободы блокируются. Формально такое поведение не нарушает GPLv2 из-за несовершенства лицензии, не оговаривающей применение свобод ПО при использовании на целевом оборудовании.
Для решения данной проблемы и устранения иных недочётов была создана GPLv3. Однако, всему есть своя цена: если текст GPLv2 составляет 340 строк (на английском), то GPLv3 — 676 строк, то есть почти в два раза больше. Проводя аналогию с ПО: есть больше кода для обработки краевых ситуаций, но он стал сложнее для понимания простыми людьми, особенно далёкими от юридических вопросов. Сложность и запутанность лицензии — высокая цена и она отпугивает часть пользователей.
Открытые вопросы
- Обфускация изменений
- Например, патчи ядра RedHat, слитые в единое изменение, применённое к ядру . Поскольку воедино сливаются сотни как связанных, так и независимых изменений на перекрывающиеся участки кода, разбор и последующая полезная модификация данных изменений чрезвычайно усложнены. Формально GPLv2 строго соблюдается, но фактически свобода модификации и использования кода сильно ограничены.
- Форсирование несовместимых лицензий
- Проблема ZFS: лицензирование модуля ядра под свободной лицензией CDDL, несовместимой с лицензией ядра GPLv2. Краевой случай, где корпорации пытаются ослабить ограничения копилефта и многие пользователи поддерживают их, поскольку им интересы технические решения и не важны лицензионные тонкости. Юридическая проблема здесь в том, что значит <<производная/объединённая работа>>. Поскольку нет строгого юридического определения, нечистые на руку участники пытаются нарушить GPLv2, формально соответствуя ей.
- Договорные ограничения поверх лицензии
- Патчи Grsecurity: проект Grsecurity основан строго на исходных текстах ядра Linux (GPLv2) и не имеет смысла без него, но распространение кода и бинарных сборок ограничивается дополнительным договором подписки. Хотя это легально во многих юрисдикциях, базовые свободы распространения и модификации СПО нарушаются.
Пути решения проблем
Похоже, хорошего решения нет:
- Уточнение лицензий
- Более строгие и точные лицензии также будут намного больше и сложнее для понимания. Здесь могут помочь упрощённые пояснения и инструменты выбора лицензий для пользователей, как делают Creative Commons. Но серьёзный подход всё равно потребует полного ознакомления с текстом лицензии.
- Развитие культуры отношения к лицензиям
- На данный момент утопический сценарий, но было бы хорошо поднять культуру до уровня, когда затыкание лазеек было бы не нужным, потому ими никто не пользуется.