Так, SELinux робить Red Hat (і будь-який інший дистрибутив Linux, який фактично використовує його) більш безпечним, припускаючи, що він фактично використовується.
SELinux реалізує обов'язковий контроль доступу . Звичайні дозволи Unix, ACL тощо, реалізують дискреційний контроль доступу . Двоє доповнюють один одного.
Для роботи SELinux потрібна політика, яка визначає, які дії в системі можуть бути дозволені. Хоча можливо створити всю системну політику з нуля, більшість дистрибутивів Linux постачають політику, засновану на так званій довідковій політиці . Це означає, серед іншого, що конфігурація SELinux між дистрибутивами буде дуже подібною. (Більшість дистрибутивів Linux надає довідкову політику SELinux доступною у своїх сховищах пакетів, хоча вона може бути встановлена за замовчуванням.)
SELinux працює за допомогою обмеження користувачів та процесів виконувати лише ті дії, дозволені їм у політиці. За замовчуванням політика полягає у запереченні, тому якщо політика прямо не дозволяє дію, вона не відбувається. Ось чому ви так часто стикаєтеся з проблемою, коли SELinux забороняє щось, що ви намагаєтеся зробити.
З іншого боку, це також запобігає виходу з ладу навіть подвигів, навіть 0 днів. Наприклад, якщо ваш веб-сервер (Apache) експлуатується, шкода обмежується лише тими речами, до яких Apache може отримати доступ. /etc/shadowНаприклад, він не зміг би прочитати ваш файл, навіть із віддаленим використанням root. Хоча дозволи Unix (DAC) дозволяють кореням читати файл, SELinux (MAC) не дозволяє компрометованому процесу виходити за межі.
Велика проблема полягає в тому, що для служби повинен бути завантажений модуль політики SELinux. Якщо ви встановите службу на свій ящик, яка не містить модуля політики SELinux, вона запуститься невлаштовано і зможе робити все, що завгодно. SELinux не застосовуватиметься до нього.
Ще одна річ, яку ви повинні знати, це все про булеви . Ці налаштовані параметри надаються політикою SELinux для їх налаштування під конкретні установки та дозволу або заборонити доступ на основі локальних потреб конфігурації. Наприклад, ви можете надати Apache доступ до акцій Samba, дозволити Samba ділитися домашніми каталогами користувачів та багатьма іншими потенційно корисними речами, необхідними для деяких налаштувань, але не для інших.
Найкращий посібник по SELinux, який я бачив на даний момент, - це Посібник користувача Red Hat з підвищеною безпекою . Це допоможе вам швидко встати та працювати, а також заповнити довідкові відомості про те, що відбувається. Він також включає вичерпне керівництво з усунення несправностей, яке допомагає запустити ваш процес під SELinux.
Це корисно?
SELinux захищає від процесів (і користувачів, якщо ви обмежили своїх користувачів), які роблять несподівані речі. Це суттєво обмежує шкоду, яку може завдати віддалений експлуатування. Якщо ви ніколи не зазнавали віддаленого компромісу, вам (1) пощастило, і (2), ймовірно, новому. Якщо ви вже працювали віддалений компроміс, ви , звичайно , не хочете, щоб це ніколи НЕ повторилося.
У домашній обстановці це не так корисно , якщо у вас вдома не трапляються послуги з інтернетом (а це роблять деякі люди). У цьому випадку застосовується все сказане вище.
SELinux може бути останньою справою, яка стоїть між вашими даними та зловмисником із 0-денним експлуатом, який дійсно цього хоче. Якщо ви можете використовувати його, чому б вам не так?