SELinux. За и против.

https://www.packtpub.com/networking-and-servers/selinux-system-administration
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html...
и бложик Dan Walsh'а.

Есть ли доказательства, что АНБ лютого зверя создали и к пользователям лезут?

Да. Смотри на kernel.org.

Годное. Даже свежее книгу нашел халявную.

И блог понравился.

чтооо? можно подробнее, пожалуйста?

На сколько я понимаю главная проблема в том что из коробки он запрещает очень много всего (сталкивался, например, с тем что ssh-ключи не работают если твой хомяк не в /home), плюс много софта есть, в поставке которых просто нет правил для selinux. В общем очень много руками нужно делать, по-этому его и выпиливают (или переводят в permissive). С точки зрения безопасности это может и плохо, но когда надо чтоб было готово уже вчера нет времени угадывать что ему там в очередной раз не понравилось.

АНБ лютого зверя создали и к пользователям лезут

Послушать всяких фанатов тотального опенсорса так у нас даже в пластиковом коннекторе витухи есть закладка от АНБ чтоб трафик прослушивать, фотографировать пользователя и записывать его разговоры 24x7.

Против SELinux, за AppArmor.

На сколько я понимаю главная проблема в том что из коробки он запрещает очень много всего (сталкивался, например, с тем что ssh-ключи не работают если твой хомяк не в /home), плюс много софта есть, в поставке которых просто нет правил для selinux

Применительно к щадящему targeted, в котором и так по умолчанию почти всё unconfined, кроме самых популярных сетевых демонов, это просто означает отсутствие дополнительных ограничений на программу относительно POSIX DAC и не может вообще никак влиять на широту adoption. Но если вы, к примеру, служите в минобороны сша и у вас не targeted, то, как легко догадаться, этот самый "софт без правил в поставке" работать не будет в принципе, собственно, что и нужно.

SELinux чист, если бы в нем была грязь, то его бы давно из ядра выкинули.

на selinux стоит печать красноглазия
взяли кувалду и начали забивать ею гвозди

сталкивался, например, с тем что ssh-ключи не работают если твой хомяк не в /home

У хомяка должно быть object_r:user_home_dir_t, а в /home он или нет — неважно.

В общем очень много руками нужно делать, по-этому его и выпиливают (или переводят в permissive).

Это делают копипастеры интернетовских хаутушек, не осилившие ls -Z

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

Ну что там угадывать-то?
cat /var/log/audit/audit.log | audit2why
В выхлопе всё будет написано, даны советы и приведены команды для исправления ситуации. Родина и партия уже всё пожевала и в рот положила. :)

Я же не говорю что проблемы нельзя решить и настроить selinux нереально.

Кстати да, раньше плюсом была возможность наворотить что-то нестандартное. Это же было и минусом, когда сам забываешь, что и как наворотил. Попав в чужую систему разобраться в ней требовалось много времени. Селинукс приучает к стандартным методам, которые укладываются в схемы правил. Иначе настраивать приходится слишком много. У этого есть тоже и плюсы и минусы.

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

Ну что там угадывать-то?

Вы и правы и нет. Когда «нужно вчера» и для безопасности это роли не играет, а в данный момент время на изучение сущности нет (от слова совсем, одна ночь на взлет тех же демонов что и на других системах без selinux поднимал), да в попу... отключил и все.
Поймите правильно, я не против selinux, более того считаю его в чем-то полезным, просто описал свой первый опыт столкновения с ним :)

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

И где вы увидели «неосиляторство» в моем сообщении?
Возможно вы не поняли. Попробую еще раз пояснить: " просто описал свой первый опыт столкновения с ним" и «нужно вчера», если проще то давно это было.
Далее

Поймите правильно, я не против selinux, более того считаю его в чем-то полезным, просто описал свой первый опыт столкновения с ним :)

Надеюсь в таком изложении вам доступнее?

И где вы увидели «неосиляторство» в моем сообщении?

В этом:

Вы и правы и нет. Когда «нужно вчера» и для безопасности это роли не играет, а в данный момент время на изучение сущности нет (от слова совсем, одна ночь на взлет тех же демонов что и на других системах без selinux поднимал), да в попу... отключил и все.

Возможно вы не поняли.

Да, я не понял к чему там вся первая часть.

В этом:

Просто задам вопрос:
Вам приходилось один и тот же набор демонов «внезапно» (за несколько часов) поднимать на другой версии/дистрибутива онтопика? При условии что на других дистрах без se все так же работает. Т.е. типовая конфигурация.
И теперь основной вопрос: Вы потратите время (которого почти нет) на изучение? Или все-таки сначала выполните задачу?

Вам приходилось один и тот же набор демонов «внезапно» (за несколько часов) поднимать на другой версии/дистрибутива онтопика? При условии что на других дистрах без se все так же работает. Т.е. типовая конфигурация.

Вот не понимаю я такие вводные. Если, допустим, нам нужно поднять сервис вместо дебиана\слакваре\etc без selinux, на centos или федора, то я подразумеваю наличие в этой задаче selinux (а так же, других фич требуемой платформы: поддержку systemd, соотвествие принятому в платформе fhs, системные либы и зависимости). Ведь есть же какие-то обоснования перевода сервисов на другую платформу. Например, на Solaris, или FreeBSD, или RHEL - и тогда нужно заниматься адаптированием под неё. Иначе какой смысл-то? Берешь докер, и хоть под виндой поднимай. Подход «если я привык эникействовать на убунте под рутом, то мне и solaris с rhel кажутся убунтой под рутом, иначе, я их такими сделаю» - это просто дно.

Селинукс приучает к стандартным методам

Это не только про SELinux.

Если администрировать систему кое-как, вставляя bash-портянки в rc.local, хардкод в xorg.conf, сертификаты и ключи размазывая по /home и /opt ровным слоем, редактируя файлы в /usr.., про инит-скрипты уж даже не говоря, то да, все эти подсистемы начиная с менеджера пакетов приносят проблемы и страдания, потому что админить приходится не благодаря, а вопреки.

И тогда действительно «проще» всё отключить.

Если же админить _правильно_, то половина граблей убирается просто за счет того что конфиги кладутся к конфигам, а бинарники к бинарникам. И внезапно оказывается что всё давно продумано и работает из коробки.

https://selinuxproject.org/page/Main_Page

Я разработчик, а не админ, так что у меня по определению "нетипичная конфигурация". Изучил, когда мои службы, стартующие из confined-доменов, получали по рукам, благо сделать это надо один раз. А вы если тоже уже изучили, могли бы и только нужный домен предлагать перевести в permssive, а не всё выключать. И обратно после отладки вернуть тоже забыли написать в том сообщении, к которому я придрался.

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

Точно у меня сегодня плохо с объяснениями. :( Но попробую последний раз. Это было давно, именно поэтому я и написал " просто описал свой первый опыт столкновения с ним", т.е. тогда я с ним столкнулся впервые.

Если, допустим, нам нужно поднять сервис вместо дебиана\слакваре\etc без selinux, на centos или федора, то я подразумеваю наличие в этой задаче selinux (а так же, других фич требуемой платформы: поддержку systemd, соотвествие принятому в платформе fhs, системные либы и зависимости).

Почему именно так надо было, слишком долго описывать, но сам факт оказался именно таким. А сама задача оказалась весьма проста, поднять именно на копейкоси и времени как писал выше было на это несколько часов.
ЗЫ Хорошо что всяких systemd в те времена еще небыло. :)

Я разработчик, а не админ

Вот и ответ. У вас времени больше чем «несколько часов на взлет»

ЗЫ Хорошо что всяких systemd в те времена еще небыло. :)

А в systemd, кстати, домен для службы тоже удобненько задаётся <3 (разумеется, в политике должен быть разрешён транзишн в него из init-а, иначе отлуп получит сам systemd.)

Послушать всяких фанатов тотального опенсорса так у нас даже в пластиковом коннекторе витухи есть закладка от АНБ чтоб трафик прослушивать, фотографировать пользователя и записывать его разговоры 24x7.

Тащемта, так и есть. Ты зачем, думаешь, на мышка такой большой DPI пилят? Чтобы ты на фото лучше получался.

Вот и ответ. У вас времени больше чем «несколько часов на взлет»

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

каждый хост чуть ли не ручной работы продукт

На самом деле нет. :)
Только если первый раз и с нуля.
Потом проще шаблон подпилить.

Админы честно говоря, я думал, тоже всё с шаблонов деплоят и в ус не дуют.

Я знаю/умею/работаю «обе стороны медали» как девел. так и админ. Правда девел. давно запустил, так... осталось несколько крупных проектов которые поддерживаю. Админу фиг простят неработу сервера «здесь и сейчас», девелопер в этих временных рамках свободнее.

SElinux просто адски непонятный если что-то не в струю (и кто-то не написал правила. Правила очень многословны, отлаживать непросто если нужно сделать строгую политику для определённой софтины. По этой причине я даже на андроиде видел его в enforced крайне редко. То есть разработка правил для SElinux это нехилый такой девелопмент сам по себе, да ещё и на птичьем языке и с затруднённой отладкой и нечитаемыми или неточными сообщениями об ошибках. Его голышом нельзя давать ни пользователям/администраторам ни разработчикам софта. Это как сайты на ассемблере писать. Если бы для SElinux какой компилятор придумали, или менее убогий анализатор, позволяющий быстро понять какие правила нужны чтобы оно заработало. Плюс оно ещё в разных релизах ядер не охватывает весь спектр функций, из-за этого приходится патчить чтобы заработали те или иные правила. Короче, SElinux - это набор сложных низкоуровневых многословных правил, которые писать сложно, а проверять корректность - ещё сложнее. Если кто-то написал policy хорошо и сделал так, что пользователь копипастит нужный шаблон в нужный файл и оно начинает работать для типовых задач - хорошо, но как только встретится нетиповая - наступает жопа, когда можно неделю провозиться чтобы написать изменение в policy. Короче, для любителей и для работы за деньги под подконтрольную с стандартным неизменным набором софта - SElinux - ok, для администрежки и подправки пары правил я бы искал что-то другое.

каждый хост чуть ли не ручной работы продукт

На самом деле нет. :)
Только если первый раз и с нуля.

Хотел подобное написать, но вы опередили :)

Послушать всяких фанатов тотального опенсорса так у нас даже в пластиковом коннекторе витухи есть закладка от АНБ чтоб трафик прослушивать, фотографировать пользователя и записывать его разговоры 24x7.

АНБ крайне важно знать на какой прон возбуждаются красноглазики из России.

Проблема в том, что команды, которые оно предложит, будут скорее всего или бесполезны или опасны.

Да, audit2why фейлит угадывать, об этом даже в книжечке написали из первого поста. Лудше сгенерировать затычку (audit2allow) и прочитать получившиеся type enforcement-правила (устанавливать необязательно), там понятнее всего КМК.

setsebool бесполезен, или опасен?

Лудше сгенерировать затычку (audit2allow) и прочитать получившиеся type enforcement-правила

audit2why покажет ту же самую затычку правил + текст.

SELinux logs an AVC message that looks like
<....>
Hard to believe users find that hard to understand.

http://danwalsh.livejournal.com/4780.html

:)

А чего пропустили сам avc denial, для полноты картины:

time->Wed Apr 5 14:38:38 2006 type=AVC_PATH msg=audit(1144262318.922:237):
path="/usr/lib/flash-plugin/libflashplayer.so" type=SYSCALL msg=audit(1144262318.922:237): arch=40000003 syscall=125 success=no exit=-13 a0=20f0000 a1=1fd000 a2=5 a3=bfca1260 items=0 pid=2714 auid=3267 uid=3267 gid=3267 euid=3267 suid=3267 fsuid=3267 egid=3267 sgid=3267 fsgid=3267 tty=(none) comm="firefox-bin"
exe="/usr/lib/firefox-1.5.0.1/firefox-bin" subj=user_u:system_r:unconfined_t:s0-s0:c0.c255
type=AVC msg=audit(1144262318.922:237): avc: denied { execmod } for pid=2714 comm="firefox-bin" name="libflashplayer.so" dev=dm-0 ino=2803062 scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tcontext=system_u:object_r:lib_t:s0 tclass=file

чего пропустили сам avc denial

ой, чё-то подумал что все и так знают как он выглядит

вобще вроде довольно понятное сообщение,
если полистать немного доку (прочиатать всю от кроки до корки)

IMHO, если сравнить усилия, которые нужно затрачивать на начальную настройку и дальнейшую поддержку правил SELinux с той пользой, которую он приносит, то окажется, что SELinux оправдан для

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

2. задротов, которым доставляет удовольствие копаться в низкоуровневых деталях и которые не желают даже думать о том, что затраты времени должны окупаться.

Видел достаточно «героев», которые на словах за то, чтобы «правильно» настроить SELinux, даже «знают», как это делать, а когда доходит до того, что вот этот сервис вот именно эту функцию не выполняет, потому что SELinux, то решение принимается быстро: «Сейчас отключу, а настраивает его пусть кто-то другой».

Я несколько раз пытался разобраться с SELinux, но так и не понял, зачем пользователя и роль разделили (т.е. зачем пользователь может работать под разными ролями - хочешь админить, становись root'ом, хочешь работать, будь пользователем, а зачем одному пользователю разные привилегии в зависимости от ситуации - я не понял, можно же создать разных пользователей), возможно, просто не нашел удачного примера. Зато понял, что это, во-первых, сложно, и, во-вторых, полезный выхлоп от SELinux не окупает затраты на него.

P.S. Если кто-то считает полезным копаться в настройке SELinux, я не возражаю.

Может быть и бесполезен, и опасен, если autid2why ошибся.
Цитата из книжки:

Sadly, it isn't always right in its deduction. Try it out against 
the same denial for which we used sealert :

# ausearch –m avc –ts today | audit2why
type=AVC msg=audit(1371204434.608:475): avc: denied { getattr }
for pid=1376 comm="httpd" path="/var/www/html/infocenter" dev="dm-1"
ino=1183070 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:o
bject_r:user_home_t:s0 tclass=dir

Was caused by:
The boolean httpd_read_user_content was set incorrectly.
Description:
Determine whether httpd can read generic user home content files.

Allow access by executing:
# setsebool -P httpd_read_user_content 1

The audit2why utility here didn't consider that the context of the target location
was wrong, and suggest to enable the web server permission to read user content.

В RedHat SELinux работает из коробки, копаться не нужно.
В большинстве случаев настройка тривиальна - переменную там поменять, или контекст на директорию навесить. В самом крайнем случае, модуль написать.
У нас SELinux включен на 90% серверов, отключаем только в исключительных случаях. В основном там, где работает какая-нибудь проприетарная хрень, которую админим не мы, и вендор так и говорит - выключить.

зачем пользователя и роль разделили (т.е. зачем пользователь может работать под разными ролями - хочешь админить, становись root'ом, хочешь работать, будь пользователем

Из принципа least privilege. Чтобы пользователю не давать рутовые права, а дать только необходимый минимум прав через роль. SELinux обепечивает не только MAC (type enforcement), но и RBAC (Role Based Access Coontrol), вот для RBAC и нужны роли.

можно же создать разных пользователей

Создать разных Unix-пользователей? Дело в том, что пользователь SELinux и пользователь ОС - это разные вещи. Даже если пользователь ОС станет другим пользователем (например, через su), то пользователь SELinux не изменится - для SELinux он останется все тем же самым пользователем.

В RedHat SELinux работает из коробки, копаться не нужно.

В большинстве случаев настройка тривиальна - переменную там поменять, или контекст на директорию навесить. В самом крайнем случае, модуль написать.

Это называется тепличные условия. А теперь представь, что есть пакет под Дебиан, в которой есть демон, папка со скриптами под php с модулем для apache, база и куча скриптов. Демон читает конфиг, работает с базой, получает данные по сети, случает порт, запускает кучу скриптов из хомяка и /usr/share. php скрипты делают ничуть не меньше, база стандартная. В общем обычное приложение и оно раздается пользователям. Нужно написать конфиг для SELinux (пользователь захотел, чтобы работало в RedHat). Всем разработчикам насрать на SELinux, они и так неплохо зарабатывают, оставаясь в теплом уютном мирке только своего кода, разработчик php мало интересуется, разработкой демона и наоборот. Как только ты в это ввязываешься, нужно досконально разобраться в SELinux и том что делает приложение (куда подключается, какие файлы трогает, какие скрипты запускает, т.е. пройтись по каждой менюшке и вызвать все возможные API). Далее тебе придется все это поддерживать (т.е. разработчик внес изменения в код, он стал обращаться к файлам в другом месте и ему насрать, что SELinux не даст туда обратиться, зато когда ты об этом прочитаешь в BugTracker'е, то босс захочет, чтобы ты это исправил вчера, в результате сборка пакетов тоже на тебе). Так ты становишься конченным неудачником, который разгребает дерьмо, за которое никто другой просто не хочет даже браться. Еще возможна ситуация, что пользователь на своей машине решил перенести домашний каталог в другое место (где места побольше) - эту багу тоже будешь править ты.

Щас набегут «знатоки» и скажут, что я просто «не осилил», но как я уже написал, такие люди в подобной ситуации обычно принимают решение «пусть это дерьмо разгребает кто-то другой», зато на словах на LORе «герои».

Чтобы пользователю не давать рутовые права, а дать только необходимый минимум прав через роль.

Ты не понял. Если нужно админить, делаешь sudo su - и админишь под рутом, вопрос зачем пользователю несколько ролей (типа я сам Вася, но могу работать в роли Маши, так сделай sudo su - masha, если же интерактивному пользователю нужны права на доступ, куда неинтерактивый пользователь доступа не имеет, мне это тоже не понятно, в общем я не понимаю, зачем васе какие-то другие роли кроме роль_вася)?

Даже если пользователь ОС станет другим пользователем (например, через su), то пользователь SELinux не изменится - для SELinux он останется все тем же самым пользователем.

И поэтому пользователь после смены UID должен еще и роль сменить? Что-то мне кажется, что для начала мне нужно почитать документацию, причем от целиком и до конца, чтобы создать полную картину, а не гуглеж по конкретному сообщению об ошибке.

P.S. Ты так и не ответил на главный вопрос - зачем все это нужно. В свете соотношения затрачиваемых усилий и получаемой пользы от SELinux. При наличии возможности просто отключить SELinux.

P.P.S. С RSBAC пытался разобраться еще в Adamantix, но так и не понял зачем все эти сложности и как оно работает.

А писать правила для межсетевого экрана не жопа?

делаешь sudo su -

И? Почему не просто su? sudo на то и sudo, чтобы ограничения иметь, а не для того, чтобы разово команду с повышенными правами выполнить.

Почему не просто su?

Когда что-то админишь, а не просто выполняешь одну команду через sudo, например, если нужно будет еще и конфиги править, то проще стать рутом, все что надо сделать и вернуться к пользовательской жизни. А делать это через sudo su - или через su - (или вообще ssh root@localhost, люди, которые закрывают доступ руту через ssh ключ должны гореть в аду) - это дело личного предпочтения (какой ты хочешь вводить пароль: пользователя или админа) .

Что-то усиленно насосанное из пальца, учитывая:
path=«/var/www/html/infocenter» scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0

Надеюсь в книжке написано примерно так: «если хотите иметь меньше проблем удалите в системе /bin/mv, сделайте неисполняемым, или замените алиасом из cp+rm»?

Похвально! Не то что к безопасности, даже к сисадминству никакого отношения не имеешь. Добавь пользователя, от имени которого работает веб-сервер, в группу wheel или root. Это очень хорошо. Ибо, кто так не делает

должны гореть в аду

sudo su -

Выбирай:
sudo -i
sudo -s

папка со скриптами под php с модулем для apache, база и куча скриптов. Демон читает конфиг, работает с базой, получает данные по сети, случает порт, запускает кучу скриптов из хомяка и /usr/share.

Засунь это всё в чрут, php-fpm чрутиться умеет. А в чруте пусть хоть тонким слоем по всему FHS размазано будет. Задача вполне типовая для селинукса.
В общем, не умеешь ты набрасывать. Вот недавно в какой-то теме кто-то из веб-морды скриптом локально в телнет ходил...