Відмінності між версіями «Контроль доступу SELinux»
Donserg (Обговорення • внесок) м (Захист на Контроль доступу SELinux встановлено ([edit=sysop] (безстроково) [move=sysop] (безстроково))) |
|||
(2 проміжні версії одного користувача не показані) | |||
Рядок 8: | Рядок 8: | ||
'''Робота SELinux''' | '''Робота SELinux''' | ||
---- | ---- | ||
+ | Робота SELinux організована таким чином: | ||
+ | |||
+ | 1. Суб'єкт операційної системи (процес) намагається виконати над певним об'єктом (файлом, процесом, сокетом) деяку дію, дозволену у рамках стандартної дискреційної системи безпеки (DAC) Linux. Це призводить до запуску потоку звернень до об'єкту. | ||
+ | |||
+ | 2. Кожен запит (звернення) на виконання дії з об'єктом перехоплюється модулем безпеки Linux Security Modules і разом з контекстом безпеки суб'єкта і об'єкту передається підсистемі SELinux Abstraction & Hook Logic, що відповідає за взаємодію з LSM. | ||
+ | |||
+ | 3. Отримана інформація від підсистеми SELinux Abstraction & Hook Logic пересилається основному модулю Policy Enforcement Server (серверу реалізації політики безпеки), безпосередньо відповідальному за ухвалення рішення про доступ суб'єкта до об'єкту. | ||
+ | |||
+ | 4. Для отримання рішення про дозвіл/замкнете дії, сервер реалізації політики безпеки звертається до спеціальної підсистеми Access Vector Cache, кэширующей найбільш часто використовувані правила. | ||
+ | |||
+ | 5. Якщо AVC не містить кэшированного рішення для відповідної політики, то запит необхідної політики безпеки перенаправляється далі - в базу даних політик безпеки. | ||
+ | |||
+ | 6. Знайдена політика безпеки передається серверу політик, що приймає рішення. | ||
+ | |||
+ | 7. Якщо запрошувана дія задовольняє знайденій політиці, то операція дозволяється. Інакше операція забороняється, а уся інформація про ухвалення рішення записується в балку-файл SELinux. | ||
+ | |||
+ | Окрім ухвалення рішення про дозвіл/забороні певних дій, модуль Policy Enforcement Server відповідає також за виконання допоміжних завдань, таких як управління мітками безпеки (призначення, видалення). | ||
+ | |||
+ | Як і належить по-справжньому хорошим системам, простота схеми роботи SELinux повинна забезпечувати як надійність функціонування, так і невимогливість до ресурсів і хорошу продуктивність усієї системи забезпечення мандатного контролю доступу. | ||
+ | |||
+ | З використанням SELinux в корпоративних мережах і, тим більше, на домашніх комп'ютерах усе не так просто. SELinux відноситься до систем мандатного контролю доступу, заснованих на контролі міток (label - based). Це, зокрема, означає, що кожному об'єкту і кожному суб'єктові операційної системи має бути присвоєна мітка - контекст безпеки. У результаті, в середньому хороша політика безпеки SELinux для усієї системи містить більше ста тисяч правил (!), так що її створення, відладка і підтримка в актуальному стані віднімають занадто багато часу і сил. У реальності, створення "з нуля" такої політики безпеки для діючої або проектованої комп'ютерної системи виправдане тільки в дуже небагатьох випадках - якщо характер інформації, що зберігається і оброблюваної, вимагає виняткової надійності і захищеності сервера. Злі язики говорять, що SELinux настільки непробиваем в плані інформаційної безпеки тільки із-за своєї складності - якщо десь зловмисник зміг обійти захист, то завжди можна послатися на те, що адміністратор неправильно настроїв SELinux. | ||
+ | |||
+ | Крім того, при спробі створити правила доступу для якої-небудь певної програми адміністратор може зіткнутися з поведінкою, що не враховує обмежень SELinux. Наприклад, деякі застосування в Linux практикують частий перехід від прав суперкористувача до прав рядового користувача і назад (тобто самі намагаються реалізувати принцип найменших привілеїв - права суперкористувача фактично використовуються тільки там, де це дійсно необхідно), але таку поведінку у рамках моделі безпеки SELinux описати дуже непросто. | ||
+ | SELinux також постійно удосконалюється - як з точки зору створення і розвитку політик безпеки, так і через взаємодію з розробниками і модифікацію вже існуючих програм. |
Поточна версія на 23:30, 20 вересня 2012
Не дивлячись на те, що Linux вважається на даний момент одній з найбільш надійних операційних систем, Агентство національної безпеки (National Security Agency, NSA) вирішило ще більше посилити захищеність цієї операційної системи, внаслідок чого з'явилася SELinux () - ОС Linux з поліпшеною безпекою. Як основа SELinux використовується ОС Linux, що випускається під ліцензією GNU. Посилення захисту відбувається шляхом внесення змін як на рівні ядра, так і на рівні простору користувача, що перетворює її на дійсно "непробивну" операційну систему. Якщо ви використовуєте ядро Linux версії 2.6, для вас може стати сюрпризом, що ви працюєте з SELinux вже зараз! У цій статті описуються основні принципи, на яких побудована робота SELinux, а також їх реалізація
За допомогою SELinux можна задати явні правила того, як суб'єкти (користувачі і програми) можуть звертатися до об'єктів системи (файли і пристрої). Таким чином, можна обмежити програми, прописавши можливості їх поведінки у вигляді політики, а операційна система забезпечить її дотримання.
SELinux складається з п'яти основних компонентів: допоміжних модулів для роботи з файловою системою і для реалізації взаємодії з перехоплювачем подій Linux Security Modules, основного механізму організації контролю доступу - Policy Enforcement Server, бази даних політик безпеки системи і Access Vector Cache (AVC) - допоміжного механізму для підвищення продуктивності.
Робота SELinux
Робота SELinux організована таким чином:
1. Суб'єкт операційної системи (процес) намагається виконати над певним об'єктом (файлом, процесом, сокетом) деяку дію, дозволену у рамках стандартної дискреційної системи безпеки (DAC) Linux. Це призводить до запуску потоку звернень до об'єкту.
2. Кожен запит (звернення) на виконання дії з об'єктом перехоплюється модулем безпеки Linux Security Modules і разом з контекстом безпеки суб'єкта і об'єкту передається підсистемі SELinux Abstraction & Hook Logic, що відповідає за взаємодію з LSM.
3. Отримана інформація від підсистеми SELinux Abstraction & Hook Logic пересилається основному модулю Policy Enforcement Server (серверу реалізації політики безпеки), безпосередньо відповідальному за ухвалення рішення про доступ суб'єкта до об'єкту.
4. Для отримання рішення про дозвіл/замкнете дії, сервер реалізації політики безпеки звертається до спеціальної підсистеми Access Vector Cache, кэширующей найбільш часто використовувані правила.
5. Якщо AVC не містить кэшированного рішення для відповідної політики, то запит необхідної політики безпеки перенаправляється далі - в базу даних політик безпеки.
6. Знайдена політика безпеки передається серверу політик, що приймає рішення.
7. Якщо запрошувана дія задовольняє знайденій політиці, то операція дозволяється. Інакше операція забороняється, а уся інформація про ухвалення рішення записується в балку-файл SELinux.
Окрім ухвалення рішення про дозвіл/забороні певних дій, модуль Policy Enforcement Server відповідає також за виконання допоміжних завдань, таких як управління мітками безпеки (призначення, видалення).
Як і належить по-справжньому хорошим системам, простота схеми роботи SELinux повинна забезпечувати як надійність функціонування, так і невимогливість до ресурсів і хорошу продуктивність усієї системи забезпечення мандатного контролю доступу.
З використанням SELinux в корпоративних мережах і, тим більше, на домашніх комп'ютерах усе не так просто. SELinux відноситься до систем мандатного контролю доступу, заснованих на контролі міток (label - based). Це, зокрема, означає, що кожному об'єкту і кожному суб'єктові операційної системи має бути присвоєна мітка - контекст безпеки. У результаті, в середньому хороша політика безпеки SELinux для усієї системи містить більше ста тисяч правил (!), так що її створення, відладка і підтримка в актуальному стані віднімають занадто багато часу і сил. У реальності, створення "з нуля" такої політики безпеки для діючої або проектованої комп'ютерної системи виправдане тільки в дуже небагатьох випадках - якщо характер інформації, що зберігається і оброблюваної, вимагає виняткової надійності і захищеності сервера. Злі язики говорять, що SELinux настільки непробиваем в плані інформаційної безпеки тільки із-за своєї складності - якщо десь зловмисник зміг обійти захист, то завжди можна послатися на те, що адміністратор неправильно настроїв SELinux.
Крім того, при спробі створити правила доступу для якої-небудь певної програми адміністратор може зіткнутися з поведінкою, що не враховує обмежень SELinux. Наприклад, деякі застосування в Linux практикують частий перехід від прав суперкористувача до прав рядового користувача і назад (тобто самі намагаються реалізувати принцип найменших привілеїв - права суперкористувача фактично використовуються тільки там, де це дійсно необхідно), але таку поведінку у рамках моделі безпеки SELinux описати дуже непросто. SELinux також постійно удосконалюється - як з точки зору створення і розвитку політик безпеки, так і через взаємодію з розробниками і модифікацію вже існуючих програм.