Безпечний linux частина перша

1. Введення

На зорі розвитку електронної обчислювальної техніки про безпеку мало хто замислювався. Однокористувацький режим і не дуже складні за сучасними мірками операційні системи дозволяли власнику комп'ютера дуже добре розуміти всі процеси, що відбуваються в системі.

Потім комп'ютери стали більш поширеними і виникли проблеми, пов'язані з безпекою. Тоді на зміну концепції «дозволено все» прийшло нове правило: «дозволено все, що не заборонено». Який з двох підходів гірше? Вирішуючи все, операційна система була беззахисна перед користувачем. Однак другий підхід привів до нових проблем і появи стрімко розвиваються бізнес-напрямків: підпільного бізнесу творців вірусів і офіційного - розробників антивірусів, міжмережевих екранів і інших програм забезпечення безпеки. Сучасні ботнети, що складаються з мільйонів комп'ютерів «зомбі», прикриті ілюзією безпеки: «дозволено все, що не заборонено»!

У серії статей ми розглянемо систему AppArmor, що реалізує інший - менш популярний, але більш потужний - принцип: «заборонено все, що не дозволено явно». Бути може, його повсюдна реалізація дозволить знизити накал гонки «експлойтів» і оновлень безпеки? У першому матеріалі серії ми дамо тільки основні відомості про цю чудову розробці. У наступних - зупинимося на роботі з AppArmor докладніше, а також розглянемо інші засоби забезпечення безпеки, такі як SELinux.

2. Вразливе додаток - вразлива система?

З якими правами доступу працюють програми, запущені на вашому комп'ютері? Поштовий клієнт і браузер мають доступ до листування в jabber-клієнті, jabber-клієнтові не забороняється звертатися до вашої пошти і файлів профілю браузера. А чи так уже потрібні програмами настільки великі можливості? Для комфортної роботи цілком достатньо, щоб jabber-клієнт мав доступ тільки до каталогу з історією повідомлень і своїми настройками. Поштовому клієнтові для роботи вистачить власного каталогу з настройками, повідомленнями, плюс додаткового каталогу, з якого він буде брати і в який буде зберігати файли, що прикріплюються до листів. Інтернет-браузеру достатньо власного профілю і каталогу обміну файлами.

3. Бронювання додатків або Безпечна «пісочниця»

Одним з найбільш популярних низькорівневих програм, що реалізують захист системи на основі принципу «заборонено все, що не дозволено явно», є розробка компанії Novell - система AppArmor. Її основне призначення - захист системи від скомпрометованих (тобто зламаних) програм. Заснована такий захист на надання програмі мінімально необхідних для роботи можливостей і привілеїв. Це означає, що ваш торрент-клієнт не матиме прав на запуск програми mail. а jabber-клієнт - на доступ до каталогу електронної пошти. Іншими словами, AppArmor поміщає додаток в своєрідну «пісочницю», обмежену точно заданими можливостями, і в разі злому весь збиток, нанесений хакером через скомпрометовану програму, обмежиться лише вмістом цієї самої «пісочниці».

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

3.1. Перевіряємо статус AppArmor

Дискреційний і мандатний контроль доступу

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

Сила ДКД в простоті - це ключова причина, по якій він широко відомий і реалізований в найбільш поширених ОС.

Основні недоліки ДКД наступні:

обмеження глобальної політики: ДКД дозволяє користувачеві визначати доступ до своїх даних незалежно від глобальних політик. Якщо ДКД є глобальною політикою, то існують складності з гарантуванням узгодженості правил.
відсутність контролю інформаційного потоку: інформація може бути скопійована з одного об'єкта в інший, тоді режим контролю доступу до копії не залежить від режиму контролю доступу до оригінального об'єкту.
вразливість перед скомпрометованим ПО: політики ДКД можуть бути легко змінені власником, тому хакер, який отримав контроль над програмою, запущеної власником об'єкта, може змінити політику ДКД без відома самого власника.

Робота AppArmor заснована на профілях - кожному з додатком, що працює під контролем AppArmor, призначається профіль, який вказує, які права і можливості доступні з додатком. Для спрощення розгортання і налаштування в пакет включається набір стандартних профілів для найбільш популярних (і вимагають захисту) додатків. Також готові профілі можна знайти для багатьох поширених (в основному, серверних) програм - шукайте посилання на сайт в розділі «Посилання». Таким чином, все, що необхідно системного адміністратора, який вирішив скористатися AppArmor, - це правильний вибір додатків, які потребують обмеження привілеїв, і створення / редагування профілів безпеки.

Далі ми докладно розглянемо роботу з системою AppArmor, налаштування та встановлення стандартних профілів і перевіримо працездатність.

Зауваження 1. Для користувачів OpenSUSE в Yast2 є графічний інтерфейс до AppArmor, проте він не дуже зручний. До того ж в інших дистрибутивах такого інтерфейсу немає. Тому далі ми будемо орієнтуватися на роботу в командному рядку.

Зауваження 2. Всі зазначені нижче команди перевірялися в openSUSE 11.1 і Kubuntu 8.04. Користувачам інших дистрибутивів слід перевірити наявність портований версії AppArmor і, при необхідності, скористатися відповідними інструкціями по установці.

Щоб зменшити дистрибутивні відмінності, виконаємо в Kubuntu простеньку команду:

Як ви вже здогадалися, ця команда управляє демоном AppArmor.

Перш за все перевіримо, чи запущений AppArmor на комп'ютері.

Kubuntu видав нам наступний результат:

Висновок тієї ж самої команди в openSUSE:

Мандатний контроль доступу

МКД визначає глобальну політику безпеки, суб'єктами якої є в тому числі користувачі. Власник не може встановити права доступу до об'єкта більш слабкі, ніж визначено системною політикою. Системні політики вказують, кому дозволено доступ. Звичайні користувачі не можуть змінити політику.

Основний недолік МКД - складність створення і супроводу системної політики.

Як бачите, за замовчуванням OpenSUSE контролює більше програм, ніж Kubuntu. Розберемо докладніше, про що рапортує нам команда rcapparmor status в OpenSUSE (як представила більше інформації). Отже, модуль apparmor завантажений і готовий до використання, всього встановлено 11 профілів. Існують два можливих режиму контролю AppArmor стосовно кожного з додатком: enforce і complain. У режимі enforce система AppArmor буде обмежувати роботу програми відповідно до профілю та повідомляти про спроби порушення встановлених правил, а в режимі complain - тільки повідомляти про порушення правил, дозволяючи додатком виконувати будь-які запитувані дії. Неважко здогадатися, що другий режим використовується, як правило, для налагодження профілів (щоб відсутність якогось конкретного дозволу не порушило нормальної роботи програми), а перший режим власне і захищає систему від нештатної роботи програми. У нашому прикладі в OpenSUSE в режимі enforce працює 10 додатків, а в режимі complain - тільки одне. Про перемиканні між цими режимами буде розказано нижче.

Важливою особливістю AppArmor є те, що зіставлення профілю з додатком здійснюється згідно абсолютного шляху до запускаємо файл. Якщо ви скопіюєте, наприклад, утиліту ping з каталогу / bin / в каталог / usr / bin або перейменувати її в my_ping, то ніякі обмеження AppArmor на неї діяти вже не будуть - не буде профілю для «нової» програми. При деяких (дуже рідкісних!) Умовах ця особливість може бути використана хакером, зате вона ж дає широкі можливості (про які буде розказано в наступній статті).

Як unconfined позначені процеси, для яких профілі існують, але обмеження AppArmor не поширюються (в нашому прикладі п'ять таких програм). Це буває, коли відповідні процеси були запущені до завантаження AppArmor. Боротися з цим просто: запустіть потрібну програму і воно перейде в список enforce (або complain):

Число завантажених профілів можна збільшити - за це відповідає пакет apparmor-profiles. У OpenSUSE він вже встановлений, а в Kubuntu доведеться зробити це вручну:

Тепер перевіримо що змінилося:

3.2. Додавання профілів

документація

Загляньте в каталог / usr / share / doc / apparmor-profiles / extras в Kubuntu або / etc / apparmor / profiles / extras в OpenSUSE. Тут ви знайдете велику кількість додаткових профілів як серверних процесів, так і «десктопних» (включаючи всіма улюблену команду man). У цьому ж каталозі можна знайти, в тому числі, і профіль для Firefox і Opera - під контролем AppArmor ваш браузер стане ще більш безпечним! В імені кожного з профілів закодовано контрольоване додаток: файл usr.bin.skype призначений для програми skype, яка знаходиться в каталозі / usr / bin / skype (перший слеш відкидається, інші замінюються точкою).

Додамо цю програму до вже запущеним під контролем AppArmor. Для цього скопіюємо файл профілю в потрібний каталог і запустити знову демон AppArmor:

root: cp /usr/share/doc/apparmor-profiles/extras/usr.bin.skype /etc/apparmor.d

root: cp /etc/apparmor/profiles/extras/usr.bin.skype /etc/apparmor.d/

Тепер перезапустити демон і перевіримо, що додаток перейшло під контроль AppArmor:

3.3. Перемикання режимів контролю

Статус AppArmor в OpenSUSE і Kubuntu показав різне ставлення до режимам контролю в цих дистрибутивах: в OpenSUSE в режимі enforce знаходиться 10 додатків, в той час як в Kubuntu (після установки додаткових профілів) - всього 3, а основна частина - в режимі complain.

Для перемикання режимів контролю до складу AppArmor входять спеціальні утиліти - enforce і complain Достатньо лише вказати команду і набрати ім'я потрібного додатка. Ось, наприклад, перемикання режиму контролю для утиліти ping:

root: enforce ping

Установка вимушеного режиму для /etc/apparmor.d/bin.ping.

root: complain ping

Установка щадного режиму для /etc/apparmor.d/bin.ping.

3.4. Як це працює

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

Навіть не заглядаючи в цей профіль, легко здогадатися, що мінімально необхідні привілеї ping не включають в себе доступ до каталогів користувача. Ось і перевіримо, як веде себе AppArmor в разі нестандартної поведінки утиліти.

Спочатку невелика підготовка:

Тепер ми замінимо утиліту ping на що-небудь інше, наприклад, на cp (далі будемо діяти від імені користувача root):

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

Зауваження 1. Ми бачили, що в Ubuntu утиліта ping контролюється AppArmor в режимі complain, а в OpenSUSE - в режимі enforce. Щоб надалі не відволікатися на це невелике розходження, переведіть контроль в режим enforce:

Установка вимушеного режиму для /etc/apparmor.d/bin.ping.

Тепер спробуємо «нестандартне» поведінку (не забудьте замінити «user» в командах на правильне ім'я користувача):

Ага, значить, AppArmor заборонив нашої утиліті скопіювати файл. Що було записано в логах?

Зауваження 2. У OpenSUSE звіти AppArmor записуються в файл /var/log/audit/audit.log. а в Kubuntu повідомлення йдуть безпосередньо в / var / log / messages. Вище показано повідомлення з OpenSUSE, формат виведення в Kubuntu відрізняється незначно.

Чи не занадто зрозумілі повідомлення, але з них видно, що

type = APPARMOR_DENIED. повідомлення від AppArmor, який комусь щось заборонив;

requested_mask = "r ::", denied_mask = "r ::". тип дії, яке програма намагалася виконати і яке йому заборонили;

fsuid = 0. ідентифікатор користувача, нульовий ідентифікатор належить root;

pid = 5911. ідентифікатор процесу, саме під таким запустилася наша «виправлена» утиліта ping;

profile = "/ bin / ping". власне профіль програми.

Тепер переведемо нашу утиліту ping в режим контролю complain:

Установка щадного режиму для /etc/apparmor.d/bin.ping.

Все пройшло чудово! Файл було скопійовано. А що з'явилося нового в логах?

Основна відмінність від попередніх записів аудиту - це type = APPARMOR_ALLOWED. AppArmor дозволив виконання дії, хоча і залишив повідомлення в логах.

Не забудьте видалити результати ваших експериментів:

root: rm test test1

і повернути на місце утиліту ping:

root: mv / bin / my_ping / bin / ping

Тепер, коли ми переконалися в працездатності AppArmor і дізналися де шукати звіти про нестандартному поведінці, можна застосовувати на практиці принцип «заборонено все, що не дозволено явно».

4. Що захищати?

5. Висновок

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