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: в чем основная идея, когда может быть нужен, нужен ли вообще?

Ответ на: комментарий от Psilocybe

Не особо представляю, где такое может понадобиться.

Не должны увидеть - положить в директорию без доступа (аналогично ей права на r/x на группу). Только чтение - тем кто увидел, но не в группе на запись. Единственное, увидеть но не смочь прочитать, и при этом не потерять возможности гибко раздавать права на запись - да, тут сложно, но это совсем непонятно зачем так делать.

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

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

Файлы создаются с первично группой юзера, а затем он может им делать chgrp на вторичные, если хочет. Ещё есть режим где файлы создаются с группой директории, в которой они созданы. Это ж везде так.

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

Почему скриптовать? Это ж не скрипт. Думаю, ничего сложного.

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

если хочет

А если не хочет, может сломать совместную работу, не выставив нужную группу. И SGID бит не помеха, он не запрещает вызвать chgrp(), в отличии от SeLinux, где контекст берётся от вышестоящего каталога и можно запретить системный вызов setxattr() через который меняется контекст файла.

Думаю, ничего сложного.

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

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

он не запрещает вызвать chgrp(), в отличии от SeLinux, где контекст берётся от вышестоящего каталога и можно запретить системный вызов setxattr() через который меняется контекст файла.

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

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

Прямо именно такого нет потому же, почему selinux-ом сознательно никто не пользуется - оно жутко неудобно. А вообще похожее (настройка прав по конфигу) есть в udev и кажется в каких-то пакетных менеджерах.

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

Конечно, одной командой получить список файлов, у которых контекст отличается от заданного в конфиге — это жутко неудобно. Толи дело группы. Сменщик накосячил где-то в глубинах /var, а ты сиди и разбрайся, у какого файла/каталога неправильная группа.

SeLinux неудобен тем, что постоянно изменяется, а с учётом объёма правил, нереально постоянно отслеживать. Поэтому сложно вносить изменения, нереально сложно для ролинг дистров.

Но, SeLinux имеет достаточно много политик, по которым обрублем доступ практически до всего. А есть дистрибутив, где заморочились с группами и вобще убрали доступные для всех файлы? Чтобы можно было создавая нового служебного пользователя обрубить ему доступ до /tmp, /etc, /proc и т.д. Именно на уровне базовых групп (раз их 64к), а не AppArmor или ещё что.

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

Не видел такого дистра. Хуже того, обычно даже /home/username world-readable, хотя тут закрывается вообще элементарно. Дело не в том что возможно/невозможно, а в том что никому почти не нужно. Сейчас, когда хотят разом до всего доступ закрыть, просто изолируют прогу на уровне файловой системы (chroot и подобное) - это проще чем разбираться с кучей правил, хоть unix-прав, хоть selinux. Хотя и идеологически некрасиво тоже.

Внутри /proc кстати группы не выставить, я как-то не подумал.

firkax ★★★★★
()
26 октября 2022 г.
Ответ на: комментарий от firkax

полнейший бред — как раз концепция MAC не зависить от доступа пользователей к какому либо ресурсу. Оно ограничивает само приложение. По этому настроенные права доступа через DAC должна дополняться настройкой прав доступа через MAC если необходим механизм более безопасной системы.
В том же android даже руту не позволено делать все что угодно, в случае если на это не настроен selinux.

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

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

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

контейнеры зачастую работают на том же apparmor — что по своей сути тот же selinux (MAC)

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

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

+++

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

Без этого достаточно сложно поддерживать систему, в которой сотня групп для совместного доступа к файлам.

охх... — сотня групп... ужас то какой — мне сложно представить администрирование и десятка групп самому)))

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

Полнейший бред - это то, что ты написал. Ты путаешь низкоуровневого системного пользователя (uid, gid) и пользователя в бытовом понимании (человека, котором выдали доступ). Первое - намного более широкое понятие, он может соответствовать и так называемым «приложениям» в том числе, определяя их доступы.

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