Какой линукс является более защищенным (стабильный или новейший)

[Dreamer77]

Возник такой вопрос касательно безопасности и защищенности дистрибутивов.
Рассматривается обычная установка линукса, без дополнительной работы по обечпечению безопасности со стороны пользователя. Т.е. та безопасность которая идет напрямую от производителей дистрибутивов.

Вопрос первый:
Более защищенным и безопасным будет постоянно обновляемый (Gentoo ~arch, Arch Linux), включающий в себя последние новинки релизный (Ubuntu, Fedora) или стабильные релизы с последующим поисхом прорех в системе безопасности без обновления до новых версий (Debian, Red Hat Enterprise, Slackware)??

Вопрос второй:
Если рассматривать дистрибутивы из одной категории (например, стабильные), то какой дистрибутив является более защищенным?

Пояснение к вопросу:
Ясно дело, что в Gentoo можно собирать Hardened, с включенным SELinux, в Debian можно точно также включить SELinux или пересобирать пакеты с дополнительной защитой самостоятельно. То же касается и Red Hat & Fedora. В этом тоже есть свои прелести. И конечно зачастую при настройке политик доступа безопасность целиком зависит от человека настраивающего эту самую безопасность.

В связи с этим возникает еще один вопрос, даже два:
Если добавлять SeLinux/Apparmor, делать это прямыми руками и одинаково хорошо во всех дистриутивах, то в каком это даст наибольий эффект?
2: Есть ли среди этих дистрибутивов какой-нибудь, где добавление защиты происходит (сильно) проще чем в других?

[/dev/random]

Ясно дело, что в Gentoo можно собирать Hardened, с включенным SELinux, в Debian можно точно также включить SELinux или пересобирать пакеты с дополнительной защитой самостоятельно.

Суть Hardened далеко не в SELinux. Более того, в Gentoo есть 2 Hardened-профиля: с SELinux и без. Кроме того, есть даже не-Hardened-профиль с SELinux. А Grsecurity (в т.ч. наиболее важная его часть - PaX) кроме Hardened Gentoo есть только в мёртвых чуть более, чем полностью Adamantix и Hardened Debian. Защита от повреждения стека тоже только в HG включается во _все_ пакеты. В остальных дистрибутивах - только в избранные.

А по первому вопросу - для безопасности важна скорость выхода _исправлений_, которые могут являться, а могут не являться новыми версиями. Поэтому принадлежность к какой-либо из перечисленных вами групп не имеет значения для безопасности. Проверьте, какие дистрибутивы с какой скоростью выпускают заплатки. Когда я проверял, по этому фактору победителем у меня оказался RHEL, но, во-первых, это была очень маленькая выборка уязвимостей, а во-вторых, ситуация могла измениться. Так что проверьте сами.

И какой из этих двух факторов важнее - решать тоже вам. Это полностью субъективный вопрос.

[KiWi]

по этому фактору победителем у меня оказался RHEL

У RHEL(не CentOS и клонов!) судьба такая.

[Dreamer77]

Проверьте, какие дистрибутивы с какой скоростью выпускают заплатки.

как раз собирался заняться таким исследованием.
Как бы хорош не был RHEL, но платить за него я не буду -- не для того на линукс перешел.
Правильно ли я нашел, где смотреть эти обновления безопасности:
Debian http://www.debian.org/security/
Gentoo GLSA
Slackware http://www.slackware.com/security/

Поверхностно просмотрев видно, что для Генту последние обновления вышли 2 месяца назад. Хорошо это или плохо я не знаю.

Добавочный вопрос:
Если хорошо настроить Gentoo Hardened, добавить Selinux (или тоже в Дебиане), то так ли опасны будут найденные ошибки и медленное исправление ошибки?

[t.t]

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

Имеет. Скажем, в Debian stable только исправления и попадут. А в testing ещё и новые уязвимости. У testing сейчас есть свои security и proposed-updates, т.е. новые баги не только приходят, но и исправляются (помимо апстрима; или, точнее, вдобавок). А вот с unstable в этом смысле совсем всё плохо.

[t.t]

Кстати, только сейчас вот о чём подумал. Благодаря security/testing и testing-proposed-updates тестовую ветку можно использовать как rolling-release: в любой момент поставить из неё систему «свежее стейбла», а потом основное хранилище testing отключить и жить только на апдейтах. Тогда новые дыры по определению в систему приходить не будут (хотя изначальных скорее всего всё равно будет больше, чем в stable — это плата за свежесть).

[taaroa]

Возник такой вопрос касательно безопасности и защищенности дистрибутивов.

[ON] Оценка безопасности различных дистрибутивов Linux

https://secure.wikimedia.org/wikipedia/en/w.../Rainbow_Series
https://secure.wikimedia.org/wikipedia/en/w...perating_system
https://secure.wikimedia.org/wikipedia/en/w...perating_system

[t.t]

Возник такой вопрос касательно безопасности и защищенности дистрибутивов.

[ON] Оценка безопасности различных дистрибутивов Linux

Очень сомнительная оценка, мягко говоря.

https://secure.wikimedia.org/wikipedia/en/w.../Rainbow_Series
https://secure.wikimedia.org/wikipedia/en/w...perating_system
https://secure.wikimedia.org/wikipedia/en/w...perating_system

Защищённая система и система, производитель которой отвалил бабла за сертификацию, это немного разные вещи. (:

[/dev/random]

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

Имеет. Скажем, в Debian stable только исправления и попадут. А в testing ещё и новые уязвимости. У testing сейчас есть свои security и proposed-updates, т.е. новые баги не только приходят, но и исправляются (помимо апстрима; или, точнее, вдобавок). А вот с unstable в этом смысле совсем всё плохо.

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

[taaroa]

Возник такой вопрос касательно безопасности и защищенности дистрибутивов.

[ON] Оценка безопасности различных дистрибутивов Linux

Очень сомнительная оценка, мягко говоря.

предложите свою? желающих что-то не много, мягко говоря.

https://secure.wikimedia.org/wikipedia/en/w.../Rainbow_Series
https://secure.wikimedia.org/wikipedia/en/w...perating_system
https://secure.wikimedia.org/wikipedia/en/w...perating_system

Защищённая система и система, производитель которой отвалил бабла за сертификацию, это немного разные вещи. (:

действительно, разные вещи. но это в том случае верно, если не ходить по ссылкам и не читать certification report & security target.

[t.t]

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

Имеет. Скажем, в Debian stable только исправления и попадут. А в testing ещё и новые уязвимости. У testing сейчас есть свои security и proposed-updates, т.е. новые баги не только приходят, но и исправляются (помимо апстрима; или, точнее, вдобавок). А вот с unstable в этом смысле совсем всё плохо.

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

Да. Но непреднамеренное устранение уязвимостей всё же куда более редкий случай, чем непреднамеренное внесение новых.

[t.t]

Очень сомнительная оценка, мягко говоря.

предложите свою? желающих что-то не много, мягко говоря.

Это не повод руководствоваться негодными оценками.

Защищённая система и система, производитель которой отвалил бабла за сертификацию, это немного разные вещи. (:

действительно, разные вещи. но это в том случае верно, если не ходить по ссылкам и не читать certification report & security target.

А если прочитать, то сразу станут одинаковыми? Или к чему Вы это?

[/dev/random]

Очень сомнительная оценка, мягко говоря.

Не "сомнительная", а просто учитывающая лишь один из двух факторов: превентивную защиту от неизвестных уязвимостей. Второй фактор - скорость исправления известных уязвимостей - с ним никак не связан, и пихать их оба в одну статью было бы, мягко говоря, странно. А какой из этих факторов важнее - сугубо субъективный вопрос, как я уже говорил.

[taaroa]

Это не повод руководствоваться негодными оценками.

оценивается _превентивная_ защита, как уже отмечено выше.

А если прочитать, то сразу станут одинаковыми? Или к чему Вы это?

классический пример: winxp (без sp1), уровень по eal (только по eal) и security target.
как так, возмутится неискушённый читатель, такой высокий уровень в таком решете!!1
а вот так: сетевой кабель не подключён.

[t.t]

Очень сомнительная оценка, мягко говоря.

Не "сомнительная", а просто учитывающая лишь один из двух факторов: превентивную защиту от неизвестных уязвимостей. Второй фактор - скорость исправления известных уязвимостей - с ним никак не связан, и пихать их оба в одну статью было бы, мягко говоря, странно. А какой из этих факторов важнее - сугубо субъективный вопрос, как я уже говорил.

Я не об объекте исследования, а о методологии. Ты сам там писал, что автор поставил hardened ядро в обычный Gentoo, а писал об этом как о Hardened Gentoo.

Второй пример: там говорилось, что убунтовское ядро лучше защищено, чем дебиановское. При этом указывалась версия ядра из Debian stable, хотя на тот момент уже была более свежая в proposed-updates. А в убунте дебиановские ядерные пакеты не дорабатываются вообще, судя по списку: ни у одного пакета в этом списке нет традиционной приставки -ubuntuN в номере версии.

[watashiwa_daredeska]

Благодаря security/testing и testing-proposed-updates тестовую ветку можно использовать как rolling-release: в любой момент поставить из неё систему «свежее стейбла», а потом основное хранилище testing отключить и жить только на апдейтах. Тогда новые дыры по определению в систему приходить не будут

Есть подозрение, что многие security updates тоже не придут. Ибо если уязвимость исправляется в новой версии в upstream, то из securty-updates исправление убирают.

[t.t]

Ибо если уязвимость исправляется в новой версии в upstream, то из securty-updates исправление убирают.

Тогда отменяется. (:

[watashiwa_daredeska]

Тогда отменяется. (:

Почему же отменяется? То, что ты описал — далеко не rolling release. Rolling release включает в себя и обычные обновления, а не только security.Так что, просто sed -i 's/stable/testing/g' /etc/apt/sources.list и получим вместо stable почти rolling release testing (почти, потому что в момент предрелизного freeze обновления замедляются почти до 0).

[taaroa]

Я не об объекте исследования, а о методологии. Ты сам там писал, что автор поставил hardened ядро в обычный Gentoo, а писал об этом как о Hardened Gentoo.

ok. предлагаю несколько видоизменённую версию скрипта (by spender at grsecurity dot net).
и для сравнения на любой из paste-сервисов выложим результаты ./checksec.sh --proc-all?
p.s. особенно интересно сравнить debian c ubuntu.

[drBatty]

Slackware http://www.slackware.com/security/

ну сегодня seamonkey Патрег залатал. Там довольно оперативно работают. ИМХО всё остальное - хуже. а SELinux не нужен (ИМХО).

[Dreamer77]

... и тут я подумал: А почему когда один из дистрибутивов выпутил корректирующее исправление -- просто не разослать его всем?!!? Чтобы сразу все имели возможность получить исправленную версию.
Ведь по идее все просто
-- найдена ошибка в таком то пакете
-- помещается на сайте ОБЩЕМ об этом информация
-- кто-то исправляет
-- помещает на тот же сайт информацию с обновлением
-- все дистрибутивы проверяют и перезаливают в репозитарии

Т.е. почему нет общедистрибутивной "gnulinux.bugs.org" ??
Или она есть?

[t.t]

Тогда отменяется. (:

Почему же отменяется? То, что ты описал — далеко не rolling release. Rolling release включает в себя и обычные обновления, а не только security.Так что, просто sed -i 's/stable/testing/g' /etc/apt/sources.list и получим вместо stable почти rolling release testing (почти, потому что в момент предрелизного freeze обновления замедляются почти до 0).

Отменяется то, что я описал, а не то, как я его назвал. Что назвал неправильно — сам понимаю.

Я не об объекте исследования, а о методологии. Ты сам там писал, что автор поставил hardened ядро в обычный Gentoo, а писал об этом как о Hardened Gentoo.

ok. предлагаю несколько видоизменённую версию скрипта (by spender at grsecurity dot net).
и для сравнения на любой из paste-сервисов выложим результаты ./checksec.sh --proc-all?
p.s. особенно интересно сравнить debian c ubuntu.

Мне, к сожалению, не на чем его сейчас запускать (разве что на maemo, но не думаю, что это кому-то интересно).

[/dev/random]

-- найдена ошибка в таком то пакете
-- помещается на сайте ОБЩЕМ об этом информация
-- кто-то исправляет
-- помещает на тот же сайт информацию с обновлением
-- все дистрибутивы проверяют и перезаливают в репозитарии

-- найдена ошибка в таком-то пакете
-- нашедший сообщает об этом автору (не дистростроителю!)
-- автор выпускает исправление
-- информация об уязвимости публикуется в ченджлоге приложения и/или в CVE и т.п. Иногда, но не обязательно, создаются багрепорты в багзиллах некоторых дистрибутивов.
-- дистростроители это видят (у них всегда есть команда, мониторящая уведомления безопасности), и либо делают пакет с новой версией (если дистрибутив/ветка - rolling release), либо бэкпортируют изменение в ту версию, которая используется именно в их дистрибутиве.

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

[Dreamer77]

после всего этого создается впечатление большой разрозненности.
правильная работа софта ведь всем важна, а вот чтобы объединить усилия -- чего-то не хватает...

понятное дело, что после внесения исправления, этот пакет еще надо протестировать перед помещением в репозитарий.

Сразу мысль появляется собирать LFS и прикрутить слежку за изменениями на сайтах... и т.д.

[t.t]

Если не доверяете дистростроителям, собирайте.

[Samae1L]

Суть Hardened далеко не в SELinux. Более того, в Gentoo есть 2 Hardened-профиля: с SELinux и без. Кроме того, есть даже не-Hardened-профиль с SELinux. А Grsecurity (в т.ч. наиболее важная его часть - PaX) кроме Hardened Gentoo есть только в мёртвых чуть более, чем полностью Adamantix и Hardened Debian. Защита от повреждения стека тоже только в HG включается во _все_ пакеты. В остальных дистрибутивах - только в избранные.

Кстати. Насколько полноценный десктоп можно собрать в hardened? Как часто от его включения что-нибудь не собирается?

[/dev/random]

Кстати. Насколько полноценный десктоп можно собрать в hardened? Как часто от его включения что-нибудь не собирается?

На 32bit - очень часто. Для некоторых фичей hardened резервируется отдельный регистр процессора, после чего многим приложениям (например, mplayer) регистров не хватает.
На 64bit, где регистров гораздо больше, я ни разу не видел, чтобы что-то не собралось. Единственное, в некоторых ебилдах разработчики забывают поставить pax-mark, и после сборки приходится вручную выставлять pax-флаги на исполнимые файлы (например, всё, что содержит jit-компиляцию, требует установки флага -m). Но это бывает редко.

[Dreamer77]

Если не доверяете дистростроителям, собирайте.

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

[drBatty]

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

учитывайте ещё и размер дистрибутива - например у Патрега совсем немного больших пакетов, которые мало от чего зависят. Потому ему очень просто сделать исправление. Он и делает, часто для слаки 11, слаки 12, слаки 13, и даже сейчас для слаки 14RC1. (:

[taaroa]

Насколько полноценный десктоп можно собрать в hardened? Как часто от его включения что-нибудь не собирается?

смотря что вы подразумеваете под словосочетанием "нормальный десктоп".
если следовать предустановленным конфигурациям ядра, то проблем быть не должно.
проблемы возникают про использовании CONFIG_GRKERNSEC_CUSTOM=y. понатыкают =y без осмысления, "наугад", "до кучи"...
обычно проблемы возникают при использовании виртуальных машин и был разработан ещё один security level:

Shell

Security options ---> Grsecurity ---> [*] Grsecurity Security Level (Hardened Gentoo [virtualization]) --->

+известные проблемы в связке nvidia-drivers (проприетарный драйвер) и pax_uderef. проблема в архитектуре/дизайне драйвера.
o pax-mark -m и +jit выше уже было сказано /dev/random.
p.s. и, до кучи.