Security: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
(переработал страницу сообразно реалиям 2017 года)
 
(не показана 1 промежуточная версия этого же участника)
Строка 1: Строка 1:
{{MovedFromFreesourceInfo|AltLinux/Security}}
= ALT Linux Security =
 
== Состояние ==
== ALT Linux Security ==
=== Состояние ===
Безопасность, которая не состояние, а процесс -- зависит от того, что было сделано для обеспечения целостности установленной системы при подготовке базового дистрибутива, в рамках обновлений к нему, а также силами локального администратора.
Безопасность, которая не состояние, а процесс -- зависит от того, что было сделано для обеспечения целостности установленной системы при подготовке базового дистрибутива, в рамках обновлений к нему, а также силами локального администратора.


По первой части базовая система ALT Linux сопоставима с такими специализированными на безопасности дистрибутивами, как [http://openwall.com/Owl/ Owl GNU/*/Linux], включая множество оригинальных доработок (например, размещение большинства сервисов в <tt>chroot</tt>, зачастую с понижением и разделением привилегий; защищённая glibc с дополнительно портированной дополнительной функциональностью из OpenBSD libc, что приводит к использованию более безопасных функций рассчитанными на это программами).
По первой части базовая система ALT сопоставима с такими специализированными на безопасности дистрибутивами, как [http://openwall.com/Owl/ Owl GNU/*/Linux], включая множество оригинальных доработок (например, размещение большинства сервисов в <tt>chroot</tt>, зачастую с понижением и разделением привилегий; защищённая [http://git.altlinux.org/gears/g/glibc.git glibc] с дополнительно портированной дополнительной функциональностью из OpenBSD libc, что приводит к использованию более безопасных функций рассчитанными на это программами).
 
По части же updates на данный момент можно говорить о том, что поддержка безопасности пакетной базы Sisyphus и выпусков осуществляется на общественных началах -- силами лично Дмитрия Левина и заинтересованных майнтейнеров.


При этом [http://lists.altlinux.org/pipermail/devel/2006-October/036994.html существуют] [-1] следующие рекомендации системным администраторам и разработчикам по работе с проблемами безопасности пакетов ALT, до сих пор не вызвавшие противоречий:
По части же обновлений на данный момент можно говорить о том, что поддержка безопасности пакетной базы [[Sisyphus]], [[branches|стабильных веток]] и [[releases|выпусков]] осуществляется силами [[Компания «Базальт СПО»|ООО "Базальт СПО"]] и заинтересованных майнтейнеров [[ALT Linux Team]] при общей координации {{man|ldv}} и {{man|glebfm}}.
<pre>Как уже было сказано, наверное, стоило бы:
- сообщить майнтейнеру,
- повесить ошибку в bugzilla, с указанием источника сообщения об уязвимости и описанием её,
- далее, по возможности/желанию/прочему - сборка исправленной версии, с размещением патчей как приложений к ошибке.</pre>


Далее [http://lists.altlinux.org/pipermail/devel/2006-October/037029.html последовало] уточнение, а заодно и разъяснение многих затронутых моментов (стоит прочитать всё письмо):
Следует в явном виде сказать, что поддержка обновлениями предыдущей [[branches|стабильной ветки]] официально довольно быстро (в течение полугода) прекращается после выхода очередной стабильной ветки (фактически длительность базовой поддержки гораздо больше).
<pre>> >>>Постящий bug report и так может пометить его как security.
> >>Отметить "Security Group"? Но ведь, во-первых, никто, кроме этой группы
> >>не увидит описание проблемы,
> >Предполагается, что для этой группы ошибок важна конфиденциальность.
> Для всех пакетов? А зачем? Я понимаю, когда есть серьезная уязвимость и
> exploit для неё и это приложение используется повсеместно. Но ведь
> ежедневно находят немалое количество не очень серьезных уязвимостей,
> которые, однако, исправить нужно в обозримом будущем. Если нет общей
> системы для их учета, то приходится их писать на бумажке/в файле. И
> читать одному человеку все рассылки по уязвимостям несколько
> проблематично. Если уж элементарные баги сам найти не можешь в своем же
> и используемом самим же пакете, тогда как другие натыкаются на это
> сразу, то с этими уязвимостями ситуация еще хуже.
Идея в том, что если вы хотите сохранить конфиденциальность, то
выпомещаете bug report в эту группу.  Если же вам просто нужно дать
понять, что bug report is security sensitive, сделайте его blocker и
добавьте [security] в subject.</pre>


Следует в явном виде сказать, что поддержка предыдущей стабильной версии очень быстро (в течение месяца-двух максимум) прекращается практически полностью после выхода очередной стабильной версии Master.  Не следует также рассчитывать на поддержку произвольных пакетов -- для Master 2.4, например, вероятность сопровождения пакетов из секции <tt>main</tt> выше, чем из <tt>contrib</tt>, но также не достигает 100%.  При необходимости гарантированной поддержки следует взвесить и выбрать варианты:
Не следует также рассчитывать на поддержку произвольных пакетов.  При необходимости гарантированной поддержки следует взвесить и выбрать варианты:
* подписания договора о предоставлении техподдержки с кем-либо из поставщиков решений на базе Sisyphus;
* подписания договора о предоставлении техподдержки с кем-либо из [http://www.basealt.ru/partners/technology-partners/ поставщиков решений на базе Sisyphus];
* оговаривания с майнтейнерами критичных пакетов возможности оперативного гарантированного предоставления обновлений;
* оговаривания с майнтейнерами критичных пакетов возможности и условий оперативного гарантированного предоставления обновлений;
* поддержания безопасности требуемой части пакетной базы своими силами (желательно при этом включиться в team и предоставлять исправления для публикации в updates для пользы коллег);
* поддержания безопасности требуемой части пакетной базы своими силами (желательно при этом [[join|включиться в team]] и предоставлять исправления для публикации в репозитории для пользы коллег);
* выбор другого дистрибутива с применением к нему вышеизложенного (с очевидной коррекцией).
* выбора другого дистрибутива с применением к нему вышеизложенного (с очевидной коррекцией).


Надо также отметить, что с весны 2005 года в [http://lists.altlinux.org/pipermail/security-announce/ security-announce@] движения не наблюдается; этому было дано пояснение (по памяти) "решено, что апдейты важнее анонсов апдейтов, если времени хватает на одно из двух" (см. тж. [http://lists.altlinux.org/pipermail/security-team/2005-December/000028.html это] и [http://lists.altlinux.org/pipermail/community/2005-January/142623.html это] письма).  С декабря 2005 года существует рассылка [http://lists.altlinux.org/pipermail/security-team/ security-team@], предназначенная для синхронизации действий тех, кто решил заняться обеспечением безопасности пакетов ALT Linux.
== Рекомендации ==
* [http://lists.altlinux.org/pipermail/devel/2006-October/036994.html системным администраторам и разработчикам]
* [http://lists.altlinux.org/pipermail/devel/2006-October/037029.html добавлению сообщения об ошибке] с чувствительной информацией по проблеме безопасности
''NB: 2006 год''


=== Майнтейнеру ===
== Майнтейнеру ==
Если нашлось время исправить проблемы безопасности (или серьёзные -- функциональности) в пакете, который был собран для выпущенных дистрибутивов, то было бы неплохо опубликовать исправление.  Сделать это возможно несколькими путями:
Если нашлось время исправить проблемы безопасности (или серьёзные -- функциональности) в пакете, который был собран для выпущенных дистрибутивов, то было бы неплохо опубликовать исправление.  Сделать это возможно несколькими путями:
* [[git.alt|собрать]] в стабильную ветку репозитория;
* разместить у себя (многие имеют свои хостинговые возможности);
* разместить у себя (многие имеют свои хостинговые возможности);
* разместить на [ftp://ftp.altlinux.org/pub/people/ people];
* разместить на [http://ftp.altlinux.org/pub/people/ people].
* в [ftp://ftp.altlinux.org/pub/distributions/ALTLinux/backports backports] и, наконец,
* в [ftp://ftp.altlinux.org/pub/distributions/ALTLinux/updates updates].


Разница примерно такая:
Разница примерно такая:
* у себя вы вольны публиковать, разумеется, что захотите и анонсировать, как заблагорассудится;
* у себя вы вольны публиковать, разумеется, что захотите и анонсировать, как заблагорассудится;
* на people -- примерно то же, хоть и чуточку официальней;
* на people -- примерно то же, хоть и чуточку официальней;
* пакеты, предлагаемые в <tt>/incoming/backports/</tt>, при наличии в них исправлений серьёзных проблем следует снабжать ясным указанием на это в <tt>%changelog</tt> и желательно анонсировать в [http://lists.altlinux.org/mailman/listinfo/backports backports@] (см. тж. [http://backports.altlinux.ru/policy/ backports policy]);
* срочные и проверенные в силу критичности обновления можно заливать прямо в репозиторий; если не уверены, лучше сперва обкатать в виде тестового сборочного задания ({{cmd|ssh git.alt build --test-only ...}} с анонсом/просьбой).
* срочные и проверенные в силу критичности обновления можно заливать прямо в <tt>/incoming/updates/{2.3,2.4,3.0}/</tt>; если не уверены, лучше сперва обкатать в backports (с анонсом/просьбой).
 
=== Планы ===
* создать клон [http://sisyphus.ru sisyphus.ru], нацеленный на updates.
* настроить экземпляр qa-robot + packages на updates с постингом в более или менее официальный список рассылки. [см. тж. [http://lists.altlinux.org/pipermail/security-team/2005-December/000028.html здесь]]


=== Ссылки ===
== Ссылки ==
* [ftp://ftp.altlinux.org/pub/distributions/ALTLinux/updates/ ftp://ftp.altlinux.org/pub/distributions/ALTLinux/updates/]
* [http://cve.basealt.ru/ Анонсы исправлений уязвимостей] в сертифицированных дистрибутивах ([[СПТ]])
* [https://lists.altlinux.org/mailman/listinfo/security-team/ https://lists.altlinux.org/mailman/listinfo/security-team/]
* [http://packages.altlinux.org/ru/Sisyphus/security Пакеты с исправлениями уязвимостей] (сводка доступна и по [http://packages.altlinux.org/ru/p8/security стабильным веткам]; надо понимать, что она основана на данных <tt>%changelog</tt> пакетов)
<!--* [ftp://ftp.altlinux.org/pub/distributions/ALTLinux/updates/ ftp://ftp.altlinux.org/pub/distributions/ALTLinux/updates/]
* [https://lists.altlinux.org/mailman/listinfo/security-team/ https://lists.altlinux.org/mailman/listinfo/security-team/]-->
* [http://lists.altlinux.org/pipermail/devel/2006-July/034848.html http://lists.altlinux.org/pipermail/devel/2006-July/034848.html]
* [http://lists.altlinux.org/pipermail/devel/2006-July/034848.html http://lists.altlinux.org/pipermail/devel/2006-July/034848.html]
* [http://oss-security.openwall.org/wiki/distro-patches http://oss-security.openwall.org/wiki/distro-patches]
* [http://oss-security.openwall.org/wiki/distro-patches http://oss-security.openwall.org/wiki/distro-patches]
[[Категория:Admin]]
[[Категория:Devel]]

Текущая версия от 17:45, 14 июля 2017

ALT Linux Security

Состояние

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

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

По части же обновлений на данный момент можно говорить о том, что поддержка безопасности пакетной базы Sisyphus, стабильных веток и выпусков осуществляется силами ООО "Базальт СПО" и заинтересованных майнтейнеров ALT Linux Team при общей координации ldv@ и glebfm@.

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

Не следует также рассчитывать на поддержку произвольных пакетов. При необходимости гарантированной поддержки следует взвесить и выбрать варианты:

  • подписания договора о предоставлении техподдержки с кем-либо из поставщиков решений на базе Sisyphus;
  • оговаривания с майнтейнерами критичных пакетов возможности и условий оперативного гарантированного предоставления обновлений;
  • поддержания безопасности требуемой части пакетной базы своими силами (желательно при этом включиться в team и предоставлять исправления для публикации в репозитории для пользы коллег);
  • выбора другого дистрибутива с применением к нему вышеизложенного (с очевидной коррекцией).

Рекомендации

NB: 2006 год

Майнтейнеру

Если нашлось время исправить проблемы безопасности (или серьёзные -- функциональности) в пакете, который был собран для выпущенных дистрибутивов, то было бы неплохо опубликовать исправление. Сделать это возможно несколькими путями:

  • собрать в стабильную ветку репозитория;
  • разместить у себя (многие имеют свои хостинговые возможности);
  • разместить на people.

Разница примерно такая:

  • у себя вы вольны публиковать, разумеется, что захотите и анонсировать, как заблагорассудится;
  • на people -- примерно то же, хоть и чуточку официальней;
  • срочные и проверенные в силу критичности обновления можно заливать прямо в репозиторий; если не уверены, лучше сперва обкатать в виде тестового сборочного задания (ssh git.alt build --test-only ... с анонсом/просьбой).

Ссылки