Security

ALT Linux Security

Состояние

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

По первой части базовая система ALT Linux сопоставима с такими специализированными на безопасности дистрибутивами, как Owl GNU/*/Linux, включая множество оригинальных доработок (например, размещение большинства сервисов в chroot, зачастую с понижением и разделением привилегий; защищённая glibc с дополнительно портированной дополнительной функциональностью из OpenBSD libc, что приводит к использованию более безопасных функций рассчитанными на это программами).

По части же updates на данный момент можно говорить о том, что поддержка безопасности пакетной базы 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 с постингом в более или менее официальный список рассылки. [см. тж. здесь]

Ссылки

• Анонсы исправлений уязвимостей в сертифицированных дистрибутивах (СПТ)
• http://lists.altlinux.org/pipermail/devel/2006-July/034848.html
• http://oss-security.openwall.org/wiki/distro-patches