Какие роли играют DAC (права доступа к файлам), ACL и MAC (SELinux) в безопасности файлов Linux?

Мне нужно уточнить / подтвердить / уточнить различные роли, которые DAC, ACL и MAC играют в безопасности файлов Linux.

После некоторого изучения документации, это мое понимание стека:

SELinux должен разрешить вам доступ к объекту файла.
Если списки управления доступом к файлу (например, setfacl, getfaclдля монтирования ACL) явно разрешает / запрещает доступ к объекту, то дальнейшая обработка не требуется.
В противном случае это зависит от прав доступа к файлу (модель ЦАП rwxrwxrwx).

Я что-то пропустил? Есть ситуации, когда это не так?

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

— Кевин М.

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

— Бельмин Фернандес

Отредактировал вопрос, чтобы уточнить, что я ищу в ответах.

— Бельмин Фернандес

Ответы:

Когда процесс выполняет операцию с файлом, ядро Linux выполняет проверку в следующем порядке:

Дискреционное управление доступом (DAC) или пользовательское управление доступом. Это включает как классические проверки прав в стиле UNIX, так и списки контроля доступа POSIX (ACL) . Классические проверки UNIX сравнивают текущие UID и GID процесса с UID и GID файла, к которому осуществляется доступ, с учетом того, какие режимы были установлены (Read / Write / eXecute). Список контроля доступа расширяет классические проверки UNIX, чтобы предоставить больше возможностей для контроля разрешений.
Обязательный контроль доступа (MAC) или контроль доступа на основе политик. Это реализовано с помощью Linux Security Modules (LSM), которые больше не являются реальными модулями (раньше они были, но они были отброшены). Они включают дополнительные проверки, основанные на других моделях, кроме классических проверок безопасности в стиле UNIX. Все эти модели основаны на политике, описывающей, какие виды деятельности разрешены для какого процесса и в каком контексте.

Вот пример доступа к inode (который включает в себя доступ к файлам) для подкрепления моего ответа ссылками на онлайновую перекрестную ссылку Linux . « function_name(Имя файла: строка)» приведены для версии ядра Linux 3.14.

Функция inode_permission( fs / namei.c: 449 ) сначала проверяет разрешение на чтение для самой файловой системы ( sb_permissionв fs / namei.c: 425 ), затем вызывает __inode_permission( fs / namei.c: 394 ) для проверки на чтение / запись / выполнение разрешения и POSIX ACL для inode в do_inode_permission( fs / namei.c: 368 ) (DAC), а затем связанные с LSM разрешения (MAC) в security_inode_permission( security / security.c: 550 ).

Было только одно исключение из этого порядка (DAC, затем MAC): это было для проверок mmap. Но это было исправлено в версии ядра Linux 3.15 ( соответствующий коммит ).

— Siosm
источник

Очень подробный ответ с каноническими источниками. Благодарность!

— Бельмин Фернандес,

DAC== Discretionary Access Control, http://en.wikipedia.org/wiki/Discretionary_access_control
MAC == Mandatory Access Control, http://en.wikipedia.org/wiki/Mandatory_access_control
ACL == Access Control List, http://en.wikipedia.org/wiki/Access_control_list

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

MAC ACLСначала к запросу всегда будут применяться s, и если доступ запрещен, обработка останавливается. Если доступ разрешен, то DAC ACLприменяются s, и снова, если доступ запрещен, обработка останавливается. Только если доступ предоставлен обоими MACи DAC ACLs, пользователь может получить доступ к объекту, который он запрашивал.

SELinuxявляется MACреализацией для Linux (есть и другие), в то время как традиционные rwxправа доступа к файлам, в сочетании с владельцем и группой, образуют полное DAC ACL. SELinux«Политика», по существу MAC ACL.

— Майк Инш
источник

Откуда поступают файловые ACL (например, setfacl)?

— Бельмин Фернандес

setaclрасширяет базовые файловые системы, ACLпозволяя назначать более одного пользователя или группы ACLдля файлов и каталогов. Это также DACреализация, и поэтому применяется после SELinux MAC ACLs.

— Майк Инш

Спасибо майк Еще один вопрос: насколько я могу судить по моему тестированию, явно установленные setfaclсписки ACL переопределяют традиционные разрешения. Это правда в каждом случае?

— Бельмин Фернандес

Насколько я знаю, да, setacl/ setfacl ACLs переопределит традиционное «простое» ACLв файле.

— Майк Инш

Майк, твоя записка setfaclотносится к ответу.

— Павел Шимерда

Извините, что придумаю, но я думаю, что некоторые ответы здесь могут быть неверными. Непосредственно из http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html Fedora :

Правила политики SELinux проверяются после правил DAC. Правила политики SELinux не используются, если правила DAC сначала запрещают доступ.

— lmgtfy
источник