LINUX.ORG.RU

Зачем нужен SELinux?

 


1

3

Недавно начал использовать Oracle Linux 8 на серверах. В RHEL-подобных дистрибутивах по умолчанию включен SELinux. Периодически это приводит к различного рода ошибкам. Например, nginx не может делать proxy_pass на внешний адрес. Я решил это с помощью команды setsebool httpd_can_network_connect 1. Или другой пример: мое приложение на Node.JS падает с ошибкой avc: denied { execmem }, при запуске как systemd service. С этим я еще не разобрался.

С одной стороны я могу отключить SELinux и жить дальше, но мне стало интересно, зачем вообще нужна эта технология. Читаю доку от Red Hat. Из доки я сделал вывод, что SELinux позволяет сделать более гранулярные правила доступа к ресурсам, чем в традиционном DAC. Таким образом, каждому файлу и директории можно поставить какую-то SELinux метку, а для процесса описать политику, в которой указано что можно делать с какими-то ресурсами, а что нельзя. Но разве в DAC делается не тоже самое? Обычно для веб сервера или базы данных создается свой собственный пользователь, которому выдаются доступы к определенным каталогам, а ко всем остальным каталогам доступы запрещаются. В доке от Red Hat пишут:

For example, if the Apache HTTP Server is compromised, an attacker cannot use that process to read files in user home directories, unless a specific SELinux policy rule was added or configured to allow such access.

Но разве Apache по умолчанию настроен так, что у него есть доступ к файлам в домашних каталогах пользователей? У него отдельный пользователь, который никаких доступов в /home не имеет, если их не выдали явно. Или идея в том, что даже если я запустил Apache от своего пользователя с включенным SELinux, то и в этом случае взломанный Apache не будет иметь доступа к моему домашнему каталогу?

Получается, что SELinux это в некотором роде аналог песочниц типа jails в FreeBSD или lxc/bubblewrap в Linux?

В общем, камрады, поделитесь своими мыслями о SELinux: в чем основная идея, когда может быть нужен, нужен ли вообще?

Вы сами привели пример, касающийся tcp, это больше, чем файлы. Основная боль SeLinux, что его политики огромны, запутаны и меняются. Только ты начал понимать что происходит в RHEL 5, как уже выходит RHEL 6 и там много что по-другому.

mky ★★★★★
()

Это костыль к двум видам проблем:

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

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

Но разве Apache по умолчанию настроен так, что у него есть доступ к файлам в домашних каталогах пользователей?

Думаю /home по дефолту world-readable (чтобы нубам было удобнее не париться на настройками доступа). Повторю, если всё правильно настроишь то оно не нужно.

firkax ★★★★★
()

Apache - неудачный пример. Пример получше - OpenSSH. Демон sshd работает из-под рута. Если злоумышленник сломает sshd, он не получит доступа к домашним каталогам пользователей (только к их публичным ключам, на которых специальный контекст).

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Не понял: sshd же запускает шел для пользователя, который уже имеет доступ к домашним каталогам. Если sshd взломан, кто мешает запустить шел и оттуда уже получить доступ к нужным файлам? Или это как-то иначе работает?

Goganchic ★★
() автор топика

SELinux (или какой-нибудь AppArmor) нужен для повышения безопасности, т.к. стандартными пермишнами всё настроить невозможно. Например, контроль сетевой активности, контроль доступа к экрану и клавиатуре, и т.д.

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

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

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

Контейнеры гораздо проще… Хотя у них есть свои приколы тоже, и их тоже надо уметь готовить, и это тоже потеря времени.

emorozov
()

Это называется мандатный доступ. Он позволяет более широко разграничивать права, чем стандартный «юзер:группа». Например, можно выставить Иванову низкий уровень доступа к документам, но к определенному документу дать доступ уровнем выше, если это нужно. Стандартными средствами такого не добиться.

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

LongLiveUbuntu ★★★★★
()

SELinux нужен когда известно, что именно нужно каждому процессу и хочется запретить шаг вправо/влево на случай если этот процесс скомпрометирован. В идеале настраивается ментейнерами дистрибутива.

У него отдельный пользователь, который никаких доступов в /home не имеет

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

приложение на Node.JS падает с ошибкой avc: denied { execmem }, при запуске как systemd service

Потому, что JIT пишет и выполняет одну и ту же память, что кроме JIT бывает разве что при buffer overflow.

x3al ★★★★★
()

Допустим, у тебя есть комп. На компе стоит скайп, скайп сделан на электроне. Чтобы это говнище работало как надо, надо чтобы оно запустило 100500 запакованных либ на js, среди которых, ВНЕЗАПНО, оказалась та, что решит смеха ради спереть твои ключи, лежащие в папке .ssh. Т.к. скайп работает от твоего юзера, у него есть доступы к всему, что имеет твой юзер, потому на системе без selinux нет никаких препятствий, чтобы спереть с твоего компа .ssh да и вообще все фотки с причинным местом, и даже запустить камеру и посмотреть на твоё недоумевающее лицо.

Но представим, что на компьютере есть selinux. Теперь твоё приложение запускается в каком-то контексте. И в рамках этого контекса имеет определённые права. На все попытки пролезть получает access denied и ещё алерт поднимается. Но это в идеальном мире.

Как показывает практика, selinux на компах нужен строго для того, чтобы ты добавил selinux=0 в опции ядра, потому что тебе стало лень с ним разбираться.

u0000
()
Ответ на: комментарий от LongLiveUbuntu

Например, можно выставить Иванову низкий уровень доступа к документам, но к определенному документу дать доступ уровнем выше, если это нужно.

Шо это за уровни доступа к документу, которые можно нарезать селинуксом тоньше, чем ACL?

thesis ★★★★★
()
Ответ на: комментарий от thesis

Шо это за уровни доступа к документу, которые можно нарезать селинуксом тоньше, чем ACL?

тут не то что тоньше, тут «по-другому». 2 процесса, оба под рутом, но один работает под доменом audio скажем. он сможет читать asoundrc, другие рутовые - нет. и ты скажешь, группы то же самое что и selinux домены. нет. имея рута id группы у процесса можно поменять, как минимум. группы могут контролировать только доступ к файлам. домены - вплоть до вызова сисколлов. т.е можно сказать, вот эти процессы, под таким то доменом не могут звать ptrace, хоть они и рутовые. ибо нехер.

vvviperrr ★★★★★
()
Ответ на: комментарий от firkax
  1. системные администраторы ленятся правильно настраивать базу юзеров и групп и расставлять соответствующие права на файлы, а так же файрволл

При этом они не ленятся настраивать SELinux. Занятно, занятно.

Psilocybe ★★★★
()

Ну в хитрых случаях он теоретически может помешать хакеру поиметь тебя полностью.
На практике тебя всегда поимеют настолько, что тебе уже будут не очень важны нюансы типа «у меня угнали дампы всех БД, но БОЖЕ, КАКОЕ СЧАСТЬЕ, что они не смогли прочитать хомяки (на виртуалке, где кроме субд больше ничего и нет).
Есть еще запуск неких „недоверенных приложений“, т.е. блобов типа зума или скайпа. Но для них действительно гораздо проще создать отдельного юзера, разве что фоточки шарить будет неудобно.
На практике захотел ты смотреть в браузере список аренды дхцп-сервера (текстовый файл), и ой, извольте пердолиться, потому что безопасная безопасность подверглась грозной угрозе.

thesis ★★★★★
()
Ответ на: комментарий от thesis

Ну в хитрых случаях он теоретически может помешать хакеру поиметь тебя полностью.

да даже не в хитрых. много рут эксплоитов осталось после того, как в android-6 selinux перевели в enforcing? а гайки с каждой версией все закручиваются.

vvviperrr ★★★★★
()
Ответ на: комментарий от Psilocybe

Ленятся. Кто вообще в ынтерпрайзном мире с «одна система = один сервис» будет трогать искоробочные политики?

thesis ★★★★★
()
Ответ на: комментарий от thesis

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

vvviperrr ★★★★★
()
Ответ на: комментарий от vvviperrr

Только что было про получение рута, и вот уже про «перло данные». Говно из маркета хмуро запрашивает у юзера права читать файлы и прёт что хочет, не?

thesis ★★★★★
()
Ответ на: комментарий от vvviperrr

можно сказать, вот эти процессы, под таким то доменом не могут звать ptrace

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

thesis ★★★★★
()
Ответ на: комментарий от thesis

Просто почти все примеры применения и обоснования нужности - они именно вот такие

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

Говно из маркета хмуро запрашивает у юзера права читать файлы и прёт что хочет, не?

так делает только самое примитивное, и даже с этими «правами» нельзя делать все, что захочешь. какие права надо запросить чтоб читать internal storage какого нить вотсапа?

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

открой аосп, system/sepolicy, и посмотри, чего там в «реальности нет».

vvviperrr ★★★★★
()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от thesis

Но для них действительно гораздо проще создать отдельного юзера

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

vvviperrr ★★★★★
()
Ответ на: комментарий от vvviperrr

А вы, Василий Иваныч, всё обещаете, всё обещаете... ((

thesis ★★★★★
()
Ответ на: комментарий от vvviperrr

А что там? Написанные гуглом ограничения для написанных гуглом сервисов? Мне с телефона неудобно.

thesis ★★★★★
()
Ответ на: комментарий от thesis

у тебя ограниченное представление об андроиде :) в первую очередь там ограничения на системщину. ну знаешь, чтоб init там в /data не лазил, если вдруг его кто попросит. а про те сервисы, что ты говоришь - еще очень далеко по стеку. вон у хуавея в их форке аоспа их вообще нет. а в некоторых применениях даже далвика/art нет. такие дела.

Мне с телефона неудобно

кампуктер купи :)

vvviperrr ★★★★★
()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от vvviperrr

у тебя ограниченное представление об андроиде :)

Ну вообще да, безо всяких смайликов. Я даже и не думал об андроиде, когда писал всю эту фигню вверху.

ну знаешь, чтоб init там в /data не лазил

...и вот поэтому я не очень понимаю, зачем нужно писать init, который может лазить в /data, а потом внешним инструментом отрезать эту возможность.

кампуктер купи :)

Я в деревню приехал и с удовольствием дичаю, мне даже ноут лень доставать.

thesis ★★★★★
()
Ответ на: комментарий от thesis

…и вот поэтому я не очень понимаю, зачем нужно писать init, который может лазить в /data

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

андроид я привел как систему с действительно работающем в реальном мире selinux-ом. других, с обязательным enforcing режимом я просто не знаю.

vvviperrr ★★★★★
()

Бывает, что /home/user с правами 755 создают. Тогда апач будет иметь доступ. В целом это просто дополнительный слой безопасности. Если считаешь, что тебе хватает юниксовых прав для реализации всех своих желаний по безопасности - отключай. Те, кто его делали, считали, что юниксовых прав не хватает и нужно больше ограничений процессам, в том числе не только для файлов, но и для других ресурсов ОС.

При работе с RHEL считаю, что отключать не нужно, если только других вариантов нет. Безопасности много не бывает. Кроме RHEL не видел его нигде настроенным, поэтому в других дистрибутивах не использую.

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

vbr ★★★★
()
Ответ на: комментарий от Goganchic

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

А в той же доке от RH про апач написано больше. Почему вы про /home спрашиваете, а про то, что SeLinux отрезает http-серверу доступ к /tmp и /var/tmp нет? Или вы правами на файлы это можете настроить?

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

 http://example.com/~rbowen/file.html  -> /home/rbowen/public_html/file.html
и в этом случае SeLinux максимум даст апачу доступ только до файлов с httpd_sys_content_t, а не до всех файлов в каталоге пользователя.

mky ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Например, можно выставить Иванову низкий уровень доступа к документам, но к определенному документу дать доступ уровнем выше, если это нужно. Стандартными средствами такого не добиться.

Прекрасно это делается стандартными средствами, не надо выдумывать. Ставишь документу группу и g+w а в /etc/group этой группе пишешь список участников, имеющих право на запись.

firkax ★★★★★
()
Ответ на: комментарий от vvviperrr

оба под рутом,

Вот в этом твоя проблема. Не поленись, сделай группы доступа к нужным файлам и назначь процессам uid, gid и вторичные группы.

вплоть до вызова сисколлов

Это конечно фича selinux-а, но в данном случае она ни при чём, т.к. не надо их делать рутовыми.

firkax ★★★★★
()
Ответ на: комментарий от thesis

Но для них действительно гораздо проще создать отдельного юзера

Я всегда отдельную виртуалку для такого создавал.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Они не нужны, пока юзеров и документов мало.
Но вообще неважно, речь о том, что селинух к этому вообще никаким боком.

thesis ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Ты какую-то чушь написал. Группа это и есть список доступа к файлу. В ней находятся ровно те, кому нужен доступ к этому файлу на запись.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ты смысла мандатных систем распределения прав не понимаешь. Когда у тебя в организации много людей, очень часто бывает трудно разбить их по группам. Вот может начальник службы безопасности читать те же документы, что и директор? А главбух? А есть еще куча людей, которым надо настроить права индивидуально и на каждого отдельную группу заводить - это безумие. Это самое простое, что приходит на ум. Ну и программам тоже разные права надо бывает, тонко настраивать. Ты, я вижу, с этим не сталкивался просто.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от firkax

сделай группы доступа к нужным файлам

один процесс хочет делать insmod, второй - ptrace. чем тут помогут группы?

не надо их делать рутовыми

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

vvviperrr ★★★★★
()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от LongLiveUbuntu

Чувак, а скажи положа руку на сердце: ты делал многоюзерскую помойку документов на политиках селинукса? Ты хотя бы планировал ее хоть раз в жизни? Ну вот честно, пока нас никто не слышит?

thesis ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

разбить их по группам

Ну ясно. А теперь прочти ещё раз моё изначальное сообщение. Где там «разбить по группам»? Там его нет. Там есть «включить в группу». Ты вообще в курсе, что кроме первичной группы, прописанной в /etc/passwd, у юзера может быть сколько угодно вторичных?

людей, которым надо настроить права индивидуально и на каждого отдельную группу заводить - это безумие

Нет, группа не на человека, группа на шаблон доступа. На каждый отличающийся (по доступу) от остальных документ - группа. В группу входят те, кто допущены. Поскольку редко какой документ прям такой уникальный со своим списком - обычно группа будет не на один файл, а сразу на пачку схожих, но даже если он один - будет группа на один файл, ничего страшного, можно назвать её users_who_have_access_to_opt_documents_doc2563222_txt. Это и есть мандатная система, и для неё не нужно никаких инородных надстроек. У одного юзера может быть до 65535 групп, всего в системе может быть до 4 миллиардов групп, вряд ли с этим возникнут проблемы. Стесняться их количества не нужно, они для этого изначально и задумывались.

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

Разные права - разные юзеры. Ну а дальше см. выше.

firkax ★★★★★
()
Ответ на: комментарий от vvviperrr

один процесс хочет делать insmod, второй - ptrace. чем тут помогут группы?

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

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

Например, с помощью ptrace один юзер в общем случае не может захватить контроль над процессом другого юзера. А над своим - пусть захватывает, в чём проблема то? Если хочешь два процесса друг от друга в этом плане изолировать - ставь им разных юзеров.

Теперь насчёт рута. Будь готов к тому, что у процесса, запущеного от рута, есть доступ куда угодно, это такая фича (про контейнеры не будем). Соответственно, если процессу не нужен доступ -куда-угодно-, то не надо запускать его от рута. Запускай его от обычного юзера, а нужные права раздай отдельно. Частично это можно делать через setcap (man 8 setcap и аналоги). Частично - создаёшь suid-root-врапперы вокруг нужных системных вызовов. Доступ к врапперам можно сделать как с помощью групп (chmod 4710), так и проверять его в коде самого враппера (тогда chmod 4711 и делаем во враппере getresuid() + getresgid() с дальнейшей их проверкой). Бонус - проверять можно не только тип системного вызова, но и его аргументы но произвольным правилам.

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

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от thesis

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

и опять же, к андроиду. ресурсы гугла позволили им продумать и написать тонны этих правил. и даже у них это было не за 1 присест. включили его изначально в jelly bean, в permissive режиме. в нем он только ругается на нарушение прав, но ничего не блокирует. и вылавливали проблемы несколько лет. заинфорсили его в 6.0. и с каждым новым релизом гайки все туже, домены все больше ограничены в своих действиях. результат - безопасность любого киктайфона на аоспе значительно выросла (не считая бекдоров от вендора, лол). кстати, надо сказать, с включенным selinux даже вендору будет проблематично поставить бекдор :) enforcing режим в user билдах андроида настолько обязателен, что его даже во время сборки выключить не просто, везде распихана куча проверок. ну и для юзера это флажок, если ты купил телефон с выключенным selinux - это кусок похаченного говна.

vvviperrr ★★★★★
()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от firkax

Речь шла про разделение доступа к файлам

речь шла об selinux в целом. просто какой то анон решил сравнить acl c mac

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

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

vvviperrr ★★★★★
()
Последнее исправление: vvviperrr (всего исправлений: 4)
Ответ на: комментарий от vvviperrr

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

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

безопасность любого киктайфона на аоспе значительно выросла (не считая бекдоров от вендора, лол

О! Я так рад, что моим телефоном владею не я, а гугло с вендором на пару! Мне так безопасненько!

даже вендору будет проблематично поставить бекдор

Да схренали, вендор что, не сможет сам подправить правила селинуха?

thesis ★★★★★
()
Ответ на: комментарий от thesis

куда, в какое место системы документооборота можно вкрячить селинух

на софт, разумеется

О! Я так рад, что моим телефоном владею не я, а гугло с вендором на пару! Мне так безопасненько!

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

Да схренали, вендор что, не сможет сам подправить правила селинуха?

почитай что такое cts, что требует для этого гугол, что оно дает вендорам. короткий ответ - конечно сможет, но не станет.

vvviperrr ★★★★★
()
Ответ на: комментарий от vvviperrr

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

Это твоё сообщение какое-то невпопад. Прочти ещё раз на что ты отвечал.

firkax ★★★★★
()
Ответ на: комментарий от vvviperrr

на софт, разумеется

Ого ничоси ты спроектировал. К черту подробности, слава селинуху, я понимаю.

почитай что такое cts, что требует для этого гугол, что оно дает вендорам

Не хочу, это похоже на работу забесплатно. А что там? Мой телефон теперь не принадлежит ни мне, ни вендору, только гуглу?

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от emorozov

Контейнеры гораздо проще… Хотя

SELinux – один из механизмов изоляции контейнеров, к слову. Контейнеры сам по себе не решают проблем контроля доступа.

i586 ★★★★★
()
Ответ на: комментарий от firkax

А какую группу будет иметь создаваемый пользователем файл?

И сколько вы будете скриптовать аналог restorecon?

mky ★★★★★
()
Ответ на: комментарий от firkax

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

Psilocybe ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.