О надёжной и безопасной сборке пакета

а также об официантке, самоделке, уникумах, горшке мёду, чёрной шляпе, о псевдосуперпользователе в частности и о единстве в трёх лицах вообще...

Лекция подготовлена по материалам доклада Дмитрия Левина на Первой Конференции разработчиков свободных программ на Протве в 2004 году. Формулировки во многих случаях авторские.

Предыстрория: "самодельные" дистрибутивы

• Обозримое число пакетов
• Кждый член сообщества пользуется почти всеми пакетами
• Разработчиков дистрибутива (maintainres) очень мало

Всё это позволяет:

• Собирать пакеты на собственной машине безо всякой изоляции
• Не (пере)собирать пакеты автоматически
• Безраздельно доверять всем разработчикам
• Оперативно отслеживать и исправлять (в основном, невольные) нарушения безопасности при сборке

Сборка на собственном ("боевом") компьютере

Ненадёжность

• "Полная" сборочная среда (инструменты для сборки всей пакетной базы)

  • неоправданно большой размер
  • несовместимость инструментов для сборки различных пакетов
• "Настраиваемая" сборочная среда
  • необходимость прав администратора для установки и удаления произвольных пакетов

  • необходимость удаления каких бы то ни было пакетов из работающей системы

• Невозможность параллельной сборки пакетов с несовместимыми сборочными зависимостями
• Уникальность и неповторимость образующейся сборочной среды

Небезопасность

• Небезопасность самой хост-системы
  • запуск произвольного кода с правами администратора при установке пакетов, требуемых для сборки
• Небезопасность пользователя, занимающегося сборкой
  • запуск произвольного кода с правами сборщика непосредственно во время сборки
• Небезопасность сборок друг от друга
  • изменение сборочного окружения
  • непосредственное воздействие на последующие сборочные процессы

Дистрибутив как предмет атаки

Дистрибутив привлекателен как объект атаки ("объект атаки" -- "предмет атаки"):

• Сборочный сервер -- все сборочные серверы
• Пакет в пакетной базе -- компьютер любого пользователя этого пакета
• Ключевой пакет в "коробочном" дистрибутиве -- все компьютеры с этим дистрибутивом
• blackhat community

Слабые места при сборке дистрибутива:

• большое число разработчиков разной квалификации
• компрометация клиентского ПО, используемого разработчиком
• компрометация ПО, собираемого разработчиком
• непосредственная атака на сборочную систему

Hasher: надёжность, безопасность, масштабируемость

Пример сборочной среды "нового поколения" -- hasher, использующийся в ALT Linux

Требования к сборочной технологии

Технология сборки элементов дистрибутива должна

• не снижать уровень безопасности хост-системы
• обеспечивать собственную безопасность от атак со стороны пакетов
• обеспечивать безопасность сборки одних пакетов от атак со стороны других пакетов
• гарантировать надёжность (воспроизводимость) результатов сборки
• обеспечивать приемлемый уровень производительности

Трёхпользовательская модель Hasher

• Сборочная среда изолируется от хост-системы с помощью chroot()

• Псевдо-root не получает прав суперпользователя (fakeroot())

• Выполняющийся от root переключатель hasher-priv

  • не выполняет самостоятельных действий (возмодна проверка на отсутствие НДВ)
  • около 50 Kb кода

"Путь пакета" в Hasher

• Порождение среды (aptbox) для работы с apt (C)

• Удаление предыдущей сборочной среды (U, R, C)

• Создание каркаса новой сборочной среды (С)

• Порождение базовой установочной среды (C, R)

• Порождение базовой сборочной среды (C, R)

• Проверка исходного пакета (U)

• Порождение сборочной среды для пакета (U, C, R)

• Сборка пакета (U)

Сайт Hasher: ftp://ftp.altlinux.org/pub/people/ldv/hasher