Міф чи реальність: SELinux може обмежитися користувачем root?

Я десь читав або чув (можливо, в курсі SELinux LinuxCBT ; але не впевнений), що є онлайн-сервери Linux, для яких також вказаний пароль кореневого користувача. Сервер Linux посилений за допомогою правил SELinux, таким чином кожен може увійти в систему з користувачем root, але не може завдати шкоди ОС.

Мені це здається міфом, але я хотів переконатися: чи можливо загартувати вікно Linux (можливо, за допомогою SELinux) таким чином, що навіть користувач root не може виконувати на ньому конкретні шкідливі дії? (Приклади: видалення системних файлів, очищення файлів журналів, зупинка критичних служб тощо)

Такий ящик для Linux стане чудовою відправною точкою для створення медового горщика .

Редагувати: Виходячи з відповіді (тепер видалено) та трохи Google, я отримав принаймні два посилання, які вказували на такі загартовані сервери Linux. На жаль, обидва сервери не працюють. Для запису я скопію сюди описи:

1) Від http://www.coker.com.au/selinux/play.html :

Безкоштовний кореневий доступ на машині SE Linux!

Щоб отримати доступ до мого ігрового автомата Debian на play.coker.com.au як root, пароль ...

Зауважте, що такі машини потребують багато навичок, якщо ви хочете їх успішно запускати. Якщо вам доведеться запитати, чи слід запускати його, то відповідь - «ні».

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

Коли ви входите в ігровий автомат SE Linux, переконайтеся, що ви використовуєте опцію -x для відключення пересилання X11 або встановлення ForwardX11 ні у вашому / etc / ssh / ssh_config-файлі перед тим, як увійти. Також переконайтеся, що ви використовуєте параметр -a для відключення пересилання пересилання агента ssh або встановлення ForwardAgent ні у вашому / etc / ssh / ssh_config файлі перед тим, як увійти. Якщо ви неправильно не відключите ці налаштування, то при вході в ігровий автомат ви ризикуєте напасти через клієнта SSH.

Існує канал IRC для обговорення цього питання, це #selinux на irc.freenode.net .

Ось швидкий FAQ

2) Від http://www.osnews.com/comments/3731

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

Реальність: так, SELinux може обмежити кореневого користувача.

Це можливо, тому що SELinux насправді не переймається поточним користувачем Unix: все, що він бачить, - це додаткові метадані, які називаються контекстом (який включає в себе, серед інших полів, поле домену ), і який дозволяє SELinux вирішувати, чи може запитувана дія бути дозволеною або ні.

Що один , як правило , задумує як кореневої користувач буде відображена в SELinux як паросток користувач Unix працюють або unconfined_tабо sysadm_tдомени SELinux. Це класичний повноцінний всемогутний користувач root.

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

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

Завдяки SELinux ми можемо надати цьому користувачеві справжню кореневу оболонку, але замість запуску unconfined_tчи sysadm_tдомену він запустить dbadm_tдомен. Це означає, що він матиме більше привілеїв, ніж обмежений користувач, але ці нові привілеї будуть обмежені тим, що потрібно для адміністрування сервера баз даних: цей користувач не зможе підробляти інші сервіси, файли та виконувати інші адміністративні команди, ніж ті суворо вимагає виконувати свою роботу.

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

Так, це можливо. Але не дуже корисно.

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

Чи можливо загартувати вікно Linux (можливо, за допомогою SELinux) таким чином, що навіть користувач root не може виконувати конкретні шкідливі дії на ньому?

Це може здатися дешевим, але легко: змінити uid кореня користувача на ненульовий. Просто увійдіть у / etc / passwd та / etc / shadow, змініть існуючі записи uid = 0 з "root" на щось інше, а потім додайте обліковий запис під назвою "root", чий uid не дорівнює нулю та не використовується.

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