Security Enhanced Linux (принципи роботи, реалізація, політики)
Принцип роботи
SELinux ( англ. Security-Enhanced Linux - Linux з покращення рівнем безопасности) - Реалізація системи примусового контролю доступу , Яка Може працюваті паралельно з класична дискреційного контролю доступу. Входить в стандартне ядро Linux . Кож для Функціонування SELinux Потрібні модіфіковані версії деяки утіліт (PS, LS, и тд), Що забезпечуються підтрімку новіх функцій ядра, и Підтримка З боку файлової системи . Залішаючісь у рамках системи контролю доступу, ОС має фундаментальні Обмеження в плані розподілу доступу процесів до ресурсів - доступ до ресурсів грунтується на правах доступу Користувача. Це класічні права RWX на трьох рівнях - власник, група-власник и Інші. У SELinux права доступу визначаються самою системою за допомога спеціально візначеної політики, ЩО працює На рівні системних вікліків и застосовуються безпосередню ядром (хоча можна реалізуваті и на рівні Програми). SELinux діє після класичної Моделі безопасности Linux.
Користувачі, політики і контексти безпеки
SELinux користувачів і ролей, які не пов'язані з безпосередніми користувачами системи і ролі. Для кожного поточного користувача або процесу, SELinux призначають три контексту рядок, що складається з ролі, ім'я користувача і домен (або типу). Ця система є більш гнучким, ніж зазвичай потрібно: як правило, більшість реальних користувачів одні й ті ж ім'я користувача SELinux, і все управління доступом здійснюється через третій тег, домен. Обставина, коли користувач може потрапити в певний домен повинен бути налаштований в політиці. Команда runcon дозволяє запуск процесу в явно заданому контексті (користувач, роль і домен), але SELinux може відмовити у переході, якщо він не схвалений конфігурації політики. Файли, мережеві порти, і інші апаратні засоби також мають SELinux контекст, що складається з назви, роль (використовується рідко), і типу. У разі файлових систем, відповідність між файлами і контексти безпеки називається маркування. Маркування визначена в файлах політики, але також може бути скоригована вручну без зміни політики. Обладнання типу досить детально, наприклад, bin_t (всі файли в папці / Bin) або postgresql_port_t (PostgreSQL порт, 5432). SELinux контекст для віддаленої файлової системи може бути заданий явно під час монтування. SELinux додає-Z перейти на команди оболонки Л.С., пс, і деякі інші, що дозволяють контекст безпеки файлів і процесів не було видно. Типові правила політики часто складаються з явних дозволів, які домени користувач повинен володіти, щоб виконувати певні дії з даною цільовою (читання, виконання, або, в разі мережевий порт, зв'язувати або підключення), і так далі. Більш складні відображення, також можливо, за участю ролей і рівнів безпеки. Типова політика складається з відображення (маркування) файл, файл правил, а також інтерфейс файлу, які визначають область переходу. Ці три файли повинні бути скомпільовані разом з SELinux інструменти для підготовки одного файлу політики. В результаті політики файл може бути завантажений в ядро, що робить його активним. Навантаження й розвантаження політики не вимагає перезавантаження. Файли політик або рукописні або можуть згенерувати з більш зручним інструментом управління SELinux. Вони, як правило, випробування в дозволяючий режим по-перше, коли порушення реєструються, але допускається. Audit2allow інструмент можна використовувати в подальшому для отримання додаткових правил, які поширюються політики, щоб дозволити всім законній діяльності додатком бути обмеженим.
Особливості
Чіткий поділ політики від правоохоронних Чітко визначені інтерфейси політики Підтримка програм запитів політики і забезпечення контролю доступу (наприклад, crond працює робочих місць в правильному контексті) Незалежно від конкретної політики і політики мовами Незалежно від конкретного цінного паперу форматів етикеток і зміст Індивідуальні етикетки і управління для об'єктів ядра і послуги Кешування доступу рішень для підвищення ефективності Підтримка змін в політиці Окремі заходи для захисту цілісності системи (домен типу), а також конфіденційність даних ( багаторівнева безпека ) Дуже гнучка політика Контроль за ініціалізацію процесу і наслідування та виконання програми Контроль за файлові системи, каталоги, файли і відкриті файлових дескрипторів Контроль за розетки, повідомлення та мережеві інтерфейси Контроль за використанням «можливості»
Реалізації
SELinux доступна з комерційної підтримки у складі Red Hat Enterprise Linux (RHEL) версії 4, і всі майбутні релізи. Це присутність також знаходить своє відображення у відповідній версії CentOS . Підтримує політику в RHEL4 є цілеспрямована політика якого спрямована на максимальну простоту використання і, таким чином, не як обмеження, як це могло б бути. Майбутні версії RHEL буде більше цілей у цілеспрямованої політики, який буде означати більш обмежувальної політики. У вільний спільнота підтримує GNU / Linux дистрибутивів Fedora був одним з найбільш ранніх усиновителів, включаючи підтримку її за умовчанням з Fedora Core 2. Інші дистрибутиви включають підтримку для нього, таких як Debian від травлення реліз, Ubuntu на 8,04 Hardy Heron, Hardened Gentoo і Yellow Dog Linux . Це також підтримується в EnGarde Secure Linux . Починаючи з версії 11.1, OpenSUSE містить SELinux "основним забезпеченням". SUSE Linux Enterprise 11 буде включати SELinux як "технологія попереднього перегляду". Існував деяка робота, щоб забезпечити SELinux пакети для Slackware, але розвиток, здається, зайшли в глухий кут. Там було працювати і в інших дистрибутивах, таких як Familiar Linux , але деякі цього була припинена через технічні причини. (Familiar Linux робота була занедбана, коли SELinux необхідні розширені атрибути файлів , підтримується в JFFS2 файлової системи.) Ранні роботи, спрямованої на стандартизацію підходу до забезпечення обов'язкового і дискреційного управління доступом (MAC і DAC) в UNIX (точніше, POSIX) обчислювальної середовища можна віднести до Trusted UNIX Агентство національної безпеки (в TRUSIX) Робоча група, яка провела з 1987 по 1991 р. і опублікував одну книгу Rainbow Book і виробляється формальної моделі і пов'язані з прототипом докази оцінки, який був в кінцевому рахунку, не опубліковано. Він був організований Чет Коутс і Маріо Tinto з АНБ Національна комп'ютерна Центр забезпечення безпеки, і керівництвом д-ра Чарльза Тесту і Брюс Вільнер з Інфосистеми технологій (Грінбелте, штат Меріленд, а пізніше, Фолс Черч, Вірджинія), вирішальний архітектори проекту TRUSIX , та членів її Моделювання підкомітету -. Стів Банч, д-р Франк Ноулз, д-р Дж. Ерік Roskos, Ларрі Вер, і Брюс Вільнер Їх зусилля, зокрема, в якості критиків менш технічно глибока робота Контроль доступу TRUSIX List (ACL) підкомітету вижити в IEEE POSIX 1003,6 "розширень безпеки для портативних операційних систем, середовищ" специфікації.
