SELinux: теорія і практика безпеки, Linux, Операційні системи, статті

Уже не перший рік Linux широко використовується в комерційних і державних організаціях. Це поле диктує свої правила гри: вимоги до надійності і безпеки систем дуже високі. Що пропонує Linux у відповідь на цей виклик?

Традиції UNIX


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


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


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


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


Рисунок 1. Права доступу в UNIX

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


Сертифікація безпеки 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 року введено стандарт ГОСТ Р ІСО / МЕК 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 рішення перевершують комерційні аналоги не тільки низькою ціною, але і принципами відкритої розробки та активної участі спільноти.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*