Security
ALT Linux Security
Состояние
Безопасность, которая не состояние, а процесс -- зависит от того, что было сделано для обеспечения целостности установленной системы при подготовке базового дистрибутива, в рамках обновлений к нему, а также силами локального администратора.
По первой части базовая система ALT Linux сопоставима с такими специализированными на безопасности дистрибутивами, как Owl GNU/*/Linux, включая множество оригинальных доработок (например, размещение большинства сервисов в chroot, зачастую с понижением и разделением привилегий; защищённая glibc с дополнительно портированной дополнительной функциональностью из OpenBSD libc, что приводит к использованию более безопасных функций рассчитанными на это программами).
По части же updates на данный момент можно говорить о том, что поддержка безопасности пакетной базы ALT Linux Sisyphus и выпусков осуществляется на общественных началах -- силами лично Дмитрия Левина и заинтересованных майнтейнеров.
При этом существуют [-1] следующие рекомендации системным администраторам и разработчикам по работе с проблемами безопасности пакетов ALT, до сих пор не вызвавшие противоречий:
Как уже было сказано, наверное, стоило бы: - сообщить майнтейнеру, - повесить ошибку в bugzilla, с указанием источника сообщения об уязвимости и описанием её, - далее, по возможности/желанию/прочему - сборка исправленной версии, с размещением патчей как приложений к ошибке.
Далее последовало уточнение, а заодно и разъяснение многих затронутых моментов (стоит прочитать всё письмо):
> >>>Постящий bug report и так может пометить его как security. > >>Отметить "Security Group"? Но ведь, во-первых, никто, кроме этой группы > >>не увидит описание проблемы, > >Предполагается, что для этой группы ошибок важна конфиденциальность. > Для всех пакетов? А зачем? Я понимаю, когда есть серьезная уязвимость и > exploit для неё и это приложение используется повсеместно. Но ведь > ежедневно находят немалое количество не очень серьезных уязвимостей, > которые, однако, исправить нужно в обозримом будущем. Если нет общей > системы для их учета, то приходится их писать на бумажке/в файле. И > читать одному человеку все рассылки по уязвимостям несколько > проблематично. Если уж элементарные баги сам найти не можешь в своем же > и используемом самим же пакете, тогда как другие натыкаются на это > сразу, то с этими уязвимостями ситуация еще хуже. Идея в том, что если вы хотите сохранить конфиденциальность, то выпомещаете bug report в эту группу. Если же вам просто нужно дать понять, что bug report is security sensitive, сделайте его blocker и добавьте [security] в subject.
Следует в явном виде сказать, что поддержка предыдущей стабильной версии очень быстро (в течение месяца-двух максимум) прекращается практически полностью после выхода очередной стабильной версии Master. Не следует также рассчитывать на поддержку произвольных пакетов -- для Master 2.4, например, вероятность сопровождения пакетов из секции main выше, чем из contrib, но также не достигает 100%. При необходимости гарантированной поддержки следует взвесить и выбрать варианты:
- подписания договора о предоставлении техподдержки с кем-либо из поставщиков решений на базе Sisyphus;
- оговаривания с майнтейнерами критичных пакетов возможности оперативного гарантированного предоставления обновлений;
- поддержания безопасности требуемой части пакетной базы своими силами (желательно при этом включиться в team и предоставлять исправления для публикации в updates для пользы коллег);
- выбор другого дистрибутива с применением к нему вышеизложенного (с очевидной коррекцией).
Надо также отметить, что с весны 2005 года в security-announce@ движения не наблюдается; этому было дано пояснение (по памяти) "решено, что апдейты важнее анонсов апдейтов, если времени хватает на одно из двух" (см. тж. это и это письма). С декабря 2005 года существует рассылка security-team@, предназначенная для синхронизации действий тех, кто решил заняться обеспечением безопасности пакетов ALT Linux.
Майнтейнеру
Если нашлось время исправить проблемы безопасности (или серьёзные -- функциональности) в пакете, который был собран для выпущенных дистрибутивов, то было бы неплохо опубликовать исправление. Сделать это возможно несколькими путями:
- разместить у себя (многие имеют свои хостинговые возможности);
- разместить на people;
- в backports и, наконец,
- в updates.
Разница примерно такая:
- у себя вы вольны публиковать, разумеется, что захотите и анонсировать, как заблагорассудится;
- на people -- примерно то же, хоть и чуточку официальней;
- пакеты, предлагаемые в /incoming/backports/, при наличии в них исправлений серьёзных проблем следует снабжать ясным указанием на это в %changelog и желательно анонсировать в backports@ (см. тж. backports policy);
- срочные и проверенные в силу критичности обновления можно заливать прямо в /incoming/updates/{2.3,2.4,3.0}/; если не уверены, лучше сперва обкатать в backports (с анонсом/просьбой).
Планы
- создать клон sisyphus.ru, нацеленный на updates.
- настроить экземпляр qa-robot + packages на updates с постингом в более или менее официальный список рассылки. [см. тж. здесь]