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

18

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

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

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

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

linux permissions selinux acl Бельмин Фернандес
источник
2
Я думаю, что вы правы. Не могли бы вы опубликовать проблему, которая у вас возникла?
Кевин М.
Я прошу прощения за некорректный вопрос. Я чувствую, что когда дело доходит до этого, я перехожу в режим «проб и ошибок». Я пытаюсь с уверенностью понять это и надеялся, что кто-нибудь сможет поделиться более четкой картиной ролей, которые играют каждая часть стека.
Бельмин Фернандес
Отредактировал вопрос, чтобы уточнить, что я ищу в ответах.
Бельмин Фернандес

Ответы:

19

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

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

  2. Обязательный контроль доступа (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
источник
Очень подробный ответ с каноническими источниками. Благодарность!
Бельмин Фернандес,
15

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.

Майк Инш
источник
1
Откуда поступают файловые ACL (например, setfacl)?
Бельмин Фернандес
1
setaclрасширяет базовые файловые системы, ACLпозволяя назначать более одного пользователя или группы ACLдля файлов и каталогов. Это также DACреализация, и поэтому применяется после SELinux MAC ACLs.
Майк Инш
Спасибо майк Еще один вопрос: насколько я могу судить по моему тестированию, явно установленные setfaclсписки ACL переопределяют традиционные разрешения. Это правда в каждом случае?
Бельмин Фернандес
Насколько я знаю, да, setacl/ setfacl ACLs переопределит традиционное «простое» ACLв файле.
Майк Инш
1
Майк, твоя записка setfaclотносится к ответу.
Павел Шимерда
5

Извините, что придумаю, но я думаю, что некоторые ответы здесь могут быть неверными. Непосредственно из 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
источник