Які ролі відіграють DAC (права доступу до файлів), ACL та MAC (SELinux) у безпеці файлів Linux?

Мені потрібно дещо роз'яснення / підтвердження / розробка різних ролей, які відіграють DAC, ACL та MAC в безпеці файлів Linux.

Після деяких досліджень з документації, це моє розуміння стека:

1. SELinux повинен надати вам доступ до файлового об’єкта.
2. Якщо списки управління доступом до файлу (наприклад, setfacl, getfaclдля монтування ACL) явно дозволяє / забороняє доступ до об'єкта, то подальша обробка не потрібна.
3. В іншому випадку це залежить від прав доступу до файлу (модель DAC rwxrwxrwx).

Я щось пропускаю? Чи бувають ситуації, коли це не так?

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

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

2. Обов’язковий контроль доступу (MAC) або контроль доступу на основі політики. Це реалізується за допомогою модулів безпеки Linux (LSM), які вже не є реальними модулями (раніше вони були, але це було відкинуто). Вони дозволяють додаткові перевірки на основі інших моделей, ніж класичні перевірки безпеки в стилі UNIX. Усі ці моделі ґрунтуються на політиці, яка описує, які операції дозволяються, для якого процесу, у якому контексті.

Ось приклад доступу до введення даних (який включає доступ до файлів) для підтвердження моєї відповіді за допомогою посилань на Інтернет крос-посилання Linux . Дані " function_name(ім'я файлу: рядок)" призначені для версії 3.14 версії ядра Linux.

Функція 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. Але це було зафіксовано у версії 3.15 ядра Linux ( відповідна комісія ).

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 ACLs завжди буде застосовано до запиту, і якщо доступ заборонено, обробка припиняється. Якщо доступ дозволений, тоді застосовується DAC ACLs, і знову, якщо доступ заборонено, обробка припиняється. Тільки якщо доступ надається обома MACі DAC ACLs, користувач може отримати доступ до запитуваного об'єкта.

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

Вибачте, що посперечаюся, але я думаю, що деякі відповіді тут можуть бути невірними. Безпосередньо з http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html : безпосередньо :

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