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

На Cryptome когда-то был репорт, который уже не сохранился(что странно). Но отыскался в вэб-архиве. Там же есть ссылка на любопытный ReplaceNsaKey.zip

Пока не знаю, с какого бока к етому подступиться. Ну и происхождение етого не известно. :)

Об этом сервисе, призванном защищать систему от утечек (и возможно, нападений) ходит много мнений – от сложности настройки до мнения как о троянском коне, заботливо всунутом АНБ в Linux в сладкой обертке.
Вот, сегодня опят наткнулся на очередной возглас недовольного параноика:

Адриан Аникушин | 2013-08-05 в 20:16:46
SELinux – Долой SELinux! Это дыра для контроля моих данных якобы позволяющая гибкое обращение к файловой системе программ.. Происки Микрософт и ЦРУ! Долой SELinux! Нет империализации моего оборудования!Вы что не видите!!!! Гавно!

http://guruadmin.ru/page/4-met.....-selinux#comment-966

У меня этот SELinux на десктопе включен по той простой причине, что GEdit, как ни странно, начинает вести себя неадекватно по отношении к обрабатываемым файлам.

А вы, уважаемые эксперты, как считаете – стоит ли использовать SElinux, или ну ее нафиг, это троянскую лошадку? (если действительно она такой и есть).

Вот, сегодня опят наткнулся на очередной возглас недовольного параноика

It was written on the internet, it must be true.

Ответы по этому поводу уже давно озвучены.

Вообщем, получается, что по сути все дистрибутивы скомпрометированы.
Неужели среди всего этого громадья не осталось действительно что-то стоящее?

https://www.pgpru.com/comment38599

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

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

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

Увидел мнение в сети:

The only thing SELinux has over apparmor is greater flexibility (for example
policies involving restricting pipes and IPC signals). When it comes to simple
filesystem-based permission or denial, apparmor and selinux are the same. And
actually apparmor may be slightly more secure due to it being simpler and not
having so many features. So when the intention is to just prevent tor browser
from accessing files it does not need (like /sys) then apparmor is totally
sufficient.

With the apparmor enabled they cannot read your dmesg (/var/log access is
blocked of course). And so is /dev/log. Even if tor browser did have a vuln, and
a root exploit was discovered, then apparmor would STILL prevent dmesg access.
And they cannot see the pci devices either. Those are present in /sys which is
heavily restricted by apparmor.

Это правда? Tails полагается на apparmor

Основная проблема SELinux – совершенно адовая сложность написания политик.
Да, базовая идея там относительно проста.
Но поскольку работает это на очень низком уровне – по сути, как фильтр системных вызовов в ядре,
то политика селинукса должа описывать каждое телодвижение защищаемого сервиса в каждой возможной позе.

Получается такая ситуация:

* Если у вас федора и на ней стоит стандартный демон типа бинда, апача или мускула,
и при этом все файлы лежат на своих исходных местах, используются только стандартные порты,
то можно поставить Enforcing-режим без проблем – всё будет работать как и раньше.

Небольшие отклонения – типа использования нестандартных портов или размещения файлов
в другой части ФС решаются относительно просто через semanage.

* Для программ пользовательского окружения эта задача красиво не решена до сих пор -
число взаимосвязей между приложениями огромно, и хотя в той же федоре можно заметить в метках
селинука в /home первые шаги в этом направлении, до полноценной изоляции каждого приложения далеко.

* Промежуточный вариант – SELinux Sandbox – периодически ломается.
В частности, в Fedora 21 сломали звук внутри selinux sandbox.
Также я не нашел красивого способа, позволяющего внутрь строго заданной песочницы прокинуть
ровно одно заданное устройство из /dev


И чем сложнее защищаемый сервис, тем более объемной требуется описывающая его рамки политика.

У нас есть специалисты и по этим вопросам © [1], [2].

Не ставьте принудительные переводы строк внутри абзацев. Это ужасно выглядит, потому что ширина окна браузера у всех разная. Движок сам делает переводы строк там, где это нужно.