SELinux: теорія і практика безпеки

1. Традиції UNIX
2. Малюнок 1. Права доступу в UNIX
3. Розвиток безпеки Linux
4. Малюнок 2. Модулі безпеки в Linux
5. Що таке SELinux
6. Малюнок 3. Модель доступу в SELinux
7. Що отримує системний адміністратор
8. Створення власної політики безпеки
9. мандатний доступ
10. Малюнок 4. Рівні та класи доступу в багаторівневих системах
11. Сертифікація безпеки Linux
12. RSBAC
13. Висновок
14. Ресурси для скачування

Традиції UNIX

Наша взаимовыгодная связь https://banwar.org/

Історія операційної системи UNIX нараховує вже понад тридцять років. Немає нічого дивного в тому, що комерційні та вільні реалізації UNIX використовуються у військових і серйозних промислових системах. Одним з важливих переваг UNIX завжди була простота і ідеологічна витриманість. Що ж стосується відкритості системи, то тут у неї взагалі немає рівних - традиції розповсюдження вихідних кодів йдуть в далекі 1970-ті. Вплив і популярність UNIX були настільки великими, що у всіх сучасних операційних системах можна побачити реалізацію тієї чи іншої ідеї з цієї операційної системи.

Модель безпеки UNIX досить проста. В основі її лежить дискреційний механізм доступу - кожен об'єкт в системі має власника, який і встановлює права доступу до об'єкта. Самі користувачі в системі фігурують у вигляді процесів - програм, запущених від їх імені. Так як в операційній системі UNIX навіть пристрої представляються у вигляді файлів, досить для кожного з них зберігати власника і права на використання цього файлу іншими користувачами системи.

Але в операційній системі можуть працювати тисячі користувачів (а така ситуація зустрічається і зараз - на мейнфреймах і інших великих машинах). При цьому списки доступу (ACL, Access Control List) для кожного файлу розростуться до гігантських розмірів. Частково цю проблему вирішує додавання груп користувачів, але ж їх число теж може бути дуже великим. Творці UNIX придумали більш елегантне рішення: для кожного файлу задаються три групи прав - права власника, права групи власника і права для всіх інших. Таким чином, всі права на файл займають лише кілька байт.

В UNIX існує три основних права доступу: читання, запис і виконання. Якщо права читання і запису очевидні та зрозумілі, то право виконання трактується по-різному для різних типів файлів. Для простих файлів воно визначає можливість запуску міститься в ньому програми. В UNIX виконувані файли можуть мати не тільки будь-яке розширення (часто вони взагалі не мають в імені символу крапки), але і вміст - це може бути відкомпілювати для даної архітектури програма або скрипт на будь-якому з підтримуваних мов програмування. А ось для директорії право виконання означає можливість "увійти" в неї.

Малюнок 1. Права доступу в UNIX

Крім комбінації з цих дев'яти прав доступу, кожен файл може мати додаткові прапори доступу: sticky-біт, специфічний для директорій, і suid-біт, застосовуваний для виконуваних файлів. Якщо позначити директорію sticky-бітом, видаляти файл в ній зможуть тільки власники, а не всі ті, хто мають права запису на цю директорію - це необхідно в "загальних директоріях", де створювати і видаляти файли може будь-хто. Suid-біт - великий головний біль системних адміністраторів, він потрібний для підвищення прав програми на час запуску.

Розвиток безпеки Linux

Успадкувавши від UNIX традиційну модель доступу, операційна система Linux зіткнулася з давно відомими проблемами безпеки. Використовуваний в ній дискреційний метод доступу надає занадто широкі можливості: будь-яка програма, запущена від імені користувача, володіє всіма його правами - може читати конфігураційні файли, встановлювати мережеві з'єднання і т.д.

Інший великою проблемою безпеки таких систем є наявність прав суперкористувача (або адміністратора). Як правило, під цією назвою розуміється рівень доступу системи, з яким працюють всі системні служби. У цьому сенсі, системні програми рівні в правах, хоча насправді кожному з них потрібно "своя" частина прав суперкористувача - звернення до мережевого інтерфейсу, читання файлів з паролями, запис повідомлень в системний журнал і т.п. Варто зловмисникові отримати контроль над однією з таких служб, і йому стане доступна вся система.

Розвиток операційних систем не стоїть на місці. Чималу роль в досягненні високого рівня безпеки Linux зіграла відкритість вихідних текстів і принципи розробників, які проповідують використання тільки відкритих стандартів. Навколо Linux виникло безліч проектів, що надають розширені можливості по управлінню доступом. Наприклад, що стали стандартному де-факто вбудовувані модулі аутентифікації (PAM, Pluggable Authentication Modules) надають гнучкий, легко розширюваний механізм аутентифікації користувачів.

Але в першу чергу безпеку операційної системи залежить від її ядра. Важливим етапом розвитку ядра Linux стало впровадження інтерфейсу модулів безпеки (LSM, Linux Security Modules). В рамках цього проекту багато внутрішні структури ядра були розширені спеціальними полями, пов'язаними з безпекою. У код багатьох системних процедур були вставлені виклики функцій управління доступом (так звані "hooks"), винесені в зовнішній модуль безпеки. Таким чином, кожен може написати власний модуль, який реалізує якусь специфічну політику безпеки.

Малюнок 2. Модулі безпеки в Linux

Формалізація зовнішнього інтерфейсу управління доступом дозволила багатьом дослідницьким групам реалізувати свої ідеї в коді для Linux. При цьому серйозну роль в поліпшенні безпеки Linux зіграли і комерційні компанії. Наприклад, компанія IBM активно бере участь в удосконаленні безпеки Linux і інших відкритих проектів. Також велика заслуга належить творцям дистрибутивів - як комерційних (в першу чергу, Red Hat і Novell), так і некомерційних, наприклад проект Hardened в рамках дистрибутива Gentoo.

Існує кілька серйозних проектів з розширення стандартної моделі безпеки в Linux. Серед них можна виділити SELinux ( Security-Enhanced Linux ), RSBAC ( Rule Set Base Access Control ) і grsecurity . У цій статті розглядається проект SELinux, який не тільки дозволяє підвищити рівень захищеності звичайній Linux-системи, але і дає можливість реалізації більш складних моделей безпеки.

Що таке SELinux

SELinux - це розширення базової моделі безпеки операційної системи Linux, що додає механізм мандатної доступу. За допомогою SELinux можна задати явні правила того, як суб'єкти (користувачі і програми) можуть звертатися до об'єктів системи (файли і пристрої). Таким чином, можна обмежити програми, прописавши можливості їх поведінки у вигляді політики, а операційна система забезпечить її дотримання.

SELinux входить в офіційне ядро ​​Linux починаючи з версії 2.6. Система розробляється Національним агентством з безпеки США (NSA, National Security Agency) при співпраці з іншими дослідницькими лабораторіями і комерційними дистрибутивами Linux. Вихідні тексти проекту доступні під ліцензією GPL.

Мандатний доступ в SELinux реалізований в рамках моделі домен-тип. У цій моделі кожен процес запускається в певному домені безпеки (рівень доступу), а всіх ресурсів (файли, директорії, сокети і т.п.) ставиться у відповідність певний тип (рівень секретності). Список правил, що обмежують можливості доступу доменів до типам, називається політикою і задається один раз в момент установки системи. Опис політики в SELinux - це набір текстових файлів, які можуть бути скомпільовані і завантажені в пам'ять ядра Linux при старті системи.

Малюнок 3. Модель доступу в SELinux

Правила мають цілком зрозумілий вид. Наприклад, в зазначеному нижче правилі для домену http-сервера дозволяється читання якихось файлів, що містять мережеву конфігурацію.

allow httpd_t net_conf_t: file {read getattr lock ioctl};

Можливості SELinux з управління доступом значно перевершують можливості базових прав UNIX. Наприклад, можна строго обмежити номер мережевого порту до якого буде прив'язуватися Ваш мережевий сервер або дозволити створення і запис у файли, але не їх видалення. Це дозволяє обмежити системні служби за допомогою явно заданого набору існуючих прав. Навіть якщо якась із таких служб буде зламана, зловмисник, маючи права суперкористувача, не зможе пробратися далі заданих обмежень.

Що отримує системний адміністратор

SELinux вже давно вийшов за рамки дослідницького проекту. Ряд дистрибутивів GNU / Linux (Red Hat / Fedora, SuSE 9, Gentoo, Debian) включають преконфігурірованний варіант цієї системи. Найбільш розвинена підтримка SELinux в дистрибутивах Red Hat (чого тільки варта створене ними повноцінне керівництво з усіх аспектів роботи і адміністрування SELinux).

На даний момент вже розроблено кілька готових політик безпеки, які можна використовувати за умовчанням на серверах і навіть домашніх комп'ютерах. Все, що потрібно від системного адміністратора - вибрати використовувану політику і перезавантажити комп'ютер з включеним SELinux. В середньому, політика безпеки SELinux для всієї системи містить більше ста тисяч правил, так що її створення і налагодження займає чимало часу.

При спробі створити правила доступу для будь-якої програми, розробник або адміністратор може зіткнутися з тим, що вона не була написана з урахуванням обмежень SELinux. Наприклад, деякі програми під UNIX практикують частий перехід від прав суперкористувача до прав простого користувача і назад (права суперкористувача фактично використовуються тільки там, де це дійсно необхідно) - така поведінка в рамках моделі безпеки SELinux описати не просто.

Багато проектів (наприклад, штатний брандмауер в Linux IPTables) ще повноцінно не включені в модель доступу SELinux. Так само, як і графічне оточення KDE - просто через об'ємності завдання. Зараз доводиться об'єднувати всі такі додатки під загальним, типовим "системним" або "призначеним для користувача" рівнем доступу, що, природно, суперечить самій ідеї повного поділу служб. Однак, проект постійно вдосконалюється - як з точки зору створення та розвитку політик безпеки, так і через взаємодію з розробниками і модифікацію програм.

Створення власної політики безпеки

Можливості SELinux виходять за рамки звичайних завдань системного адміністратора. У системах із суворим контролем за оброблюваної інформацією існує необхідність розробки власної політики безпеки, повністю відповідає вимогам підприємства. В першу чергу, мова йде про застосування SELinux в задачах військових і спец-служб.

Існуюча на папері політика безпеки, що включає опис рівнів і класів секретності, права доступу різних суб'єктів і специфіку введення і виведення інформації з системи, може бути без особливих труднощів втілена у вигляді політики SELinux. Це відкриває можливість застосування в інформаційних технологіях всіх тих методів секретності і доступу до інформації, які були напрацьовані за багато років в "паперових" системах контролю доступу.

мандатний доступ

Захист інформації завжди дуже хвилювала військових. Саме в надрах міністерств оборони виникли перші критерії і стандарти безпеки програм і операційних систем. У числі таких винаходів і метод доступу до інформації, іменований мандатних доступом (MAC, Mandatory Access Control). Вже звичний нам дискреційний спосіб (DAC, Discretionary Access Control) має на увазі установку прав доступу до файлу його власником. Тоді як при мандатному підході політика доступу до інформації задається незалежно від користувачів системи і не може бути змінена в ході роботи системи.

Часто поняття мандатної доступу поєднують з поняттям багаторівневої системи доступу (MLS, Multilevel security). В рамках цієї моделі безпеки фігурують об'єкти (пасивні сутності) і суб'єкти (активні сутності): кожному об'єкту відповідає рівень секретності (наприклад, знайомі будь-якому слова "таємно" або "цілком таємно"), а суб'єкту - рівень доступу. Зазвичай в таких системах присутній і класифікація інформації за її тематиці. Система безпеки повинна забезпечувати доступ до відповідних рівнів і класів, а також неможливість читання більш високих рівнів секретності і запис в об'єкти з більш низьким рівнем секретності (щоб не допустити просочування інформації). Це підхід реалізується в одній з найбільш поширених моделей в рамках багаторівневого доступу - моделі Белла-Ла Падула (Bell-La Padula). Важливим завданням при багаторівневому доступі є розробка формального механізму зниження рівня секретності документа, наприклад по закінченню терміну давності.

Малюнок 4. Рівні та класи доступу в багаторівневих системах

Рісунок5. Читання і запис інформації в багаторівневих системах

Широко застосовуються у військових системах обробки і зберігання інформації, методи мандатної і багаторівневого доступу зараз доступні творцям комерційних і інших систем, критичних до втрати інформації. Але за задоволення доводиться платити - вимоги до підготовки адміністраторів таких систем значно вище, а архітекторам необхідно заздалегідь і чітко опрацювати політику безпеки.

Детальніше про переваги і недоліки системи багаторівневого доступу і мандатної методу доступу можна дізнатися з роботи Річарда Сміта - Introduction to Multilevel Security .

Сертифікація безпеки Linux

Одним з важливих ринкових вимог, висунутих до операційних систем, є їх сертифікація в різних організаціях і комісіях. Найбільш впливові міжнародні стандарти інформаційної безпеки об'єднуються під назвою Загальних критеріїв (Common Criteria). У розробці положень Common Criteria беруть участь представники більш ніж 20 країн (США, Європа, Японія та інші розвинуті країни), стандарти безпеки приймаються в рамках організації ISO.

У стандартах Common Criteria безпеку операційних систем розглядається за двома ортогональним шкалами: за функціональними можливостями (так звані, профілі захисту, Protection Profiles) і по відповідності специфікації (рівень відповідності, Assurance Levels).

Існує два профілі захисту - профіль керованого доступу (CAPP, Controlled Access Protection Profile) і більш просунутий профіль міток доступу (LSPP, Labeled Security Protection Profile). CAPP формалізує давно існуючі методи організації безпеки операційних систем (починаючи з UNIX і до сучасних операційних систем) - розрахована на багато користувачів робота, дискреційний метод доступу, методи парольної аутентифікації і т.п. LSPP розширює CAPP, додаючи мандатний доступ, багаторівневу безпеку і контроль за імпортом і експортом інформації.

В рамках того чи іншого профілю захисту операційна система може сертифікуватися на певний рівнів відповідності від 1 до 7 (EAL, Evaluation Assurance Level). Кожен з рівнів висуває більш жорсткі вимоги до методів розробки і тестування операційної системи, управління конфігурацією, заручення подальшою підтримкою системи і т.п. Починаючи з 4-го рівня потрібно часткове надання початкового коду. На 7-му рівні необхідно формальне математичне доказ безпеки системи. Сам процес сертифікації полягає в перевірці апаратно-програмної платформи на відповідність зазначеним вимогам, проведення тестування та аналіз методів розробки системи.

Багато комерційних UNIX-системи, а також Windows (починаючи з Windows 2000) сертифіковані на рівень CAPP / EAL4. Завдяки зусиллям компанії IBM, операційна система Linux (точніше, дистрибутиви Red Hat Enterprise Linux і Novell SuSE) також сертифікована на це рівень. На даний момент ведеться робота по сертифікації Linux на рівень LSPP / EAL4, якого ще немає ні в однієї з широко поширених операційних систем - це стало можливо саме завдяки активному розвитку проекту SELinux.

Вітчизняні методи сертифікації безпеки операційних систем поступово наближаються до західних. З 2004 року введений стандарт ДСТУ ISO / IEC 15408 "Загальні критерії оцінки безпеки інформаційних технологій", що представляє собою переклад стандарту Common Criteria. Не за горами сертифікація комерційних дистрибутивів GNU / Linux за цим стандартом в Росії.

RSBAC

Конкуренцію SELinux може скласти проект RSBAC, який реалізує мандатний і рольової механізми доступу. Почавшись набагато раніше, проект RSBAC вже в 2000 році досяг стабільного стану. Розробники пишаються тим, що абсолютно не залежать від урядових організацій і великих компаній, написавши весь код з нуля.

Насправді, RSBAC - це середовище для створення і використання різних моделей доступу. В її рамках вже розроблені кілька модулів - просунуті мандатний і рольової механізми і просте розширення списків доступу. З теоретичної точки зору ця робота ґрунтується на публікації Абрамса і Ла Падула Узагальнена середовище для управління доступом (GFAC, Generalized Framework for Access Control).

Крім звичного адміністратора в операційну систему додається адміністратор безпеки, який може обмежити всіх користувачів (в тому числі і суперкористувача) в доступі до інформації. Це створює зайву рівень привілеїв на шляху зловмисника до повного контролю над системою, але покладає велику відповідальність на адміністратора безпеки.

Функціональність RSBAC Досить велика, з его помощью можна добиться таких цікавіх ефектів, як організація доступу до файлу только в певні години. Але явно відчуваються недолік документації, невелика кількість розробників і користувачів системи.

RSBAC поширюється під ліцензією GPL і являє собою набір патчів до поточного ядру Linux. На відміну від SELinux, в основну гілку ядра Linux RSBAC не входить - позначаються менші активність і фінансування проекту. Ряд дистрибутивів GNU / Linux підтримує RSBAC, можна відзначити Hardened Gentoo і вітчизняний ALT Linux Castle.

Висновок

Проект SELinux вибрався з пелюшок і впевнено рухається в напрямку універсального засобу забезпечення безпеки в Linux-системах. Разом з іншими відомими відкритими проектами, SELinux веде Linux до отримання високих рівнів безпеки за міжнародними стандартами Common Criteria. Зараз вже можна сказати, що рівень безпеки Linux-систем, особливо в питаннях організації мандатної доступу, досяг можливостей серйозних комерційних систем. Однак, засновані на Linux рішення перевершують комерційні аналоги не тільки низькою ціною, але і принципами відкритої розробки і активної участі спільноти.

Ресурси для скачування

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів