SELinux, AppArmor и др. системы безопасности

А может чем-то попроще воспользоваться? Apparmor-ом, например. Политики писать точно сильно проще.

Какие у него есть фундаментальные недостатки относительно SELinux?

авторы SELinux считают, что создание модели безопасности на основе путей, а не модификации файловой системы и введения доменов безопасности — неполноценно и демонстрировали, как можно обходить AppArmor. Модель безопасности AppArmor заведомо ущербна и содержит в себе концептуальный изъян.

Но как компромисс в сторону упрощённости в обмен на меньшую безопасность сойдёт.

/comment34744 Былинные чудеса поиска, sentaus. Вы слишком редко участвуете в срачах на pgpru :)

Вы слишком редко участвуете в срачах на pgpru

Точно, видимо, я тогда это не читал, иначе бы запомнил.

unknown,

демонстрировали, как можно обходить AppArmor

а можно на это ссылочку? Гугль что-то у меня молчит как партизан.

Обсуждали раз, два, три, четыре.

Этот вопрос заслуживает отдельной темы.

Только модель SELinux является формально полной из всех возможных (и за счёт попытки объять необъятное невероятно сложной, многое упирается в разработку средств упрощения работы с готовыми политиками и макроязыком для создания новых), а AppArmor простой за счёт крайней ограниченности, которую разработчики SELinux и независимые эксперты безопасности считают фундаментальным изъяном всей идеи.

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

Есть ещё концепт безопасности от Джоанны Рутковской через всеобщую раздельную виртуализацию : http://www.qubes-os.org/Home.html

Также IMHO намного слабее SELinux (хотя может использоваться совместно — какой-то монстроидально-параноидальный кошмар), завязан на закрытые проприетарные стандарты Intel, но зато искаробочный и рассчитанный на потребности рядового десктопного пользователя.

Реклама от Новелла, какой сложный и неудобный SELinux.

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

Просто, когда тыкают в ужасный код модулей SЕLinux, не понимают, что он описывает не просто права доступа, но все возможные потенциальные действия компонентов программы, включённых в домены безопасности (например — не положено такой-то проге иметь выход в сеть или положено только определённым образом, порты, сокеты, доступ к ресурсам ядра и др. и сделано это не по путям, метки принадлежности к домену проставлены на уровне ФС, а никто из домена не сможет сбросить контекст для перехода к пользователю в другом домене, если не прописаны переходы доменов, так что даже получив эксплойтом рута за пределы этих политик не выйти).

В сети есть демо-машинки с рутовым доступом по ssh для желающих помучать SELinux, никто вроде не взломал за много лет.

Спасибо, рекламу от новелля гугль давал сразу – и в основном только её, а вот вторую статью я не находил.

Сейчас нашёл ещё вот это:
http://www.isoc.org/isoc/conferences/ndss/09/pdf/16.pdf

Есть ещё концепт безопасности от Джоанны Рутковской

А реально это настроить по аналогии самому на произвольной оупенсурц-ОС, которая поддерживает Xen? Это намного сложнее просто запуска машин в виртуалках Xen + минимальная доводка?

Скорее малореально, полистайте пэдээфку к работе в конце страницы: http://qubes-os.org/Architecture.html

Много всяких наворотов, чтобы безопасный буфер обмена работал, чтобы это всё не тормозило и т.д.

Ну и концепция виртуализации для защиты раньше оценивалась скептически. Докажет ли Рутковская обратное — неизвестно.

Для безопасности API в ядре был выбран SELinux, другие альтернативы рассматривались (в том числе AppArmor):
http://lwn.net/Articles/181508/

Вот подробное описание неполноценности ограничивающих моделей ACL по путям (AppArmor, etc).

Работа, которую привели выше интересна тем, что на практике показывает, что реально используемые правила AppArmor немного безопаснее SELinux, но там рассматривается доступ, который злоумышленник может получить к дополнительным утилитам только определённым способом и не рассматриваются другие возможные способы.

Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.

SELinux Mandatory Access Control;
...: SELinux Lockdown, 1: пользователи SELinux;

Скорее малореально, полистайте пэдээфку к работе в конце страницы

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

Ну и концепция виртуализации для защиты раньше оценивалась скептически. Докажет ли Рутковская обратное — неизвестно.

"Для защиты" – понятие растяжимое: защиты от чего? В идеологии TdR виртуализация не помогает, но там имелась в виду защита от атак не слабее local root, что как раз актуально для серверных приложений, где почти нет прикладного софта (файерволлы и прочее есть часть ядра ОС). Чаще реалистичней другая угроза: выполнение дырявых приложений в ОС, которая полагается приемлемо защищёной (нет local root дыр). В таком случае как раз виртуализация и помогает, особенно в плане анонимности: дырявое приложение может получить доступ как к параметрам конфигурации системы и железа, так и к файлам других программ, выслав которые по анонимному каналу можно деанонимизировать пользователя, либо, как минимум, слить нежелательную информацию, даже если анонимность не преслудется как самоцель. Для защиты от такого сценария как раз разумно разделить программы на "классы эквивалентности", и выполнять разные программы в разных виртуалках/ОС. В целом задача решается на уровне стандартной настройки виртуализации и/или гипервизора, при этом Рутковская (как я понял), ещё как-то улучшила эту конфигурацию.

Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.

Напомнило мне известную цитату:

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Hoare. Как тонко подмечено! :)

А вы уже пробовали как-то работать хотя-бы с готовыми политиками? Про всякие тонкости с "domain transition" внятно себе представляете?

Пробовал, но познания у меня пока поверхностные на уровне SELinux User Guide от Федоры
http://docs.fedoraproject.org
Что такое "domain transition" знаю, про возможные тонкости – нет.
Спасибо за комментарии и ссылки.

А кто что может сказать хорошего/плохого про Bastille-linux?
http://bastille-linux.sourceforge.net/
http://www.ibm.com/developerwo.....=105AGX99&S_CMP=GR01

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

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

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