Unix, що народився практично разом з першими комп'ютерами, використовував дуже простий механізм безпеки (ugo), який гуру семидесятих порахували більш ніж достатнім. Але в сучасній системі, де крутяться десятки демонів і програм, запущених з-під різних учеток, грамотно розрулити всі права старими інструментами вже не виходить. А робити щось потрібно.
Дискреційний і мандатний контроль доступу
Для початку відвернемося і поміркуємо про те, що є і навіщо потрібно ще щось прикручувати. Одне із завдань будь-якої ОС - забезпечити поділ інформації, грунтуючись, у першу чергу, на вимогах конфіденційності і цілісності. Традиційна модель Unix оперує трьома параметрами - користувач, група-користувач та інші. Називається вона дискреційної (Discretionary Access Control - DAC), тобто добровільної моделлю доступу. Користувач сам визначає права доступу до своїх файлів, а програми, які виконуються мають ті ж права, що і запустив їх користувач. Механізм DAC спирається в своїй роботі тільки на тотожність користувача, ігноруючи іншу інформацію, наприклад, про роль користувача в системі, функції та рівні довіри конкретної програми і необхідності в цілісності даних. Кожна обліковий запис має повну свободу дій у межах своїх повноважень.
Як ти розумієш, розвернутися з DAC особливо ніде: все або нічого; вінда - і та дає більше можливостей по налаштуванню доступу до об'єктів. Тому сьогодні для Linux доступні рішення, що базуються на зовсім іншої моделі захисту - MAC (Mandatory Access Control, примусовий контроль доступу). Вони дозволяють визначити політики безпеки над усіма процесами і об'єктами, рішення про доступ приймається на основі більшої кількості інформації про об'єкт, а не тільки грунтуючись на тотожності користувача. Причому MAC не скасовує, а доповнює DAC, оскільки спочатку перевіряються права Unix, і, якщо вони забороняють доступ, то подальша перевірка просто не проводиться. Перевірка прав виконується тільки в тому випадку, якщо стандартні права Unix дозволяють доступ до об'єкта. Будь-який об'єкт міститься в якусь віртуальну пісочницю, яка дозволяє додатку виконувати тільки суворо регламентовані завдання. Причому при описі доступу до об'єкта конкретні реалізації можуть дотримуватися різних принципів: дуже строгі правила за типом "що не дозволено явно - заборонено" і "мінімально необхідні привілеї".
Наприклад, можна налаштувати систему так, що веб-сервер буде слухати з'єднання на строго певному порту, зможе читати файли тільки у вказаному каталозі і так далі. Тобто описати поведінку системи в її нормальному стані, створивши жорсткий каркас, за який не можна буде вискочити. Це дозволяє виконувати програми з правами звичайного користувача, а доступ до необхідних ресурсів вказувати за допомогою політик.
У дистрибутивах Linux використовуються два рішення: SELinux в RedHat і клонах, а також AppArmor в Ubuntu. У ядрі версії 2.6.30 з'явився код ще одного проекту - TOMOYO Linux, якому пророкують світле майбутнє, але поки за замовчуванням він ніде не використовується. Давай розглянемо їх особливості, а також плюси і мінуси.
Надзахищених SELinux
Проект SELinux (Security Enhanced Linux, selinuxproject.org) зародився в надрах US NSA (National Security Agency), похмурі неговіркі дядьки якого поставили собі за мету допив Linux таким чином, щоб його можна було спокійно використовувати не де-небудь, а в урядових системах. Анонсовано громадськості в 2000 році, потім розробники справедливо вирішили: навіщо щось робити самим, якщо в інтернеті є багато бажаючих? У результаті сьогодні проект розвивається під ліцензією GNU GPL і вже включений до складу ядра гілки 2.6.х, також виконана адаптація для FreeBSD та OpenSolaris.
Реалізація MAC вимагає чіткого опису правил, що може призвести до утворення великої їх кількості. Тому в SELinux використана концепція роль-заснованого контролю доступу Role-Based Access Control (RBAC), в якій визначаються ролі та доступ користувачів. Механізм захисту в SELinux носить назву Type Enforcement (TE) і дозволяє закріпити за кожним процесом і файлом, які необхідно контролювати, якусь позначку. Якщо процес, запущений від імені адміністратора, скомпрометований, то збиток, який може бути заподіяна системі, обмежений тільки тим, до чого він може звертатися, узгоджуючи з встановленими для нього правилами (а вони описують поведінку дуже тонко).
Також у SELinux реалізована багаторівнева система забезпечення безпеки (MLS, Multi-Level Security model), але її задіють тільки в особливих випадках, наприклад, в урядових багатокористувацьких системах, що вимагають надзвичайно високого рівня захисту.
Коли в процесі роботи системи суб'єкт намагається чинити якусь дію на об'єкт, SELinux приймає рішення про допустимість зазначеної дії, грунтуючись на контекстах безпеки об'єкта і суб'єкта. Суб'єкт - це процеси, виконувані від імені запустив їх користувача. Об'єкт - елементи файлової системи (файли, каталоги, посилання, сокети і пр.) або інші процеси, над якими виконуються дії. І тепер найважливіше, що відрізняє SELinux від інших рішень, описаних далі - всі важливі захисні атрибути зберігаються в контекстах безпеки. Тому файлова система повинна вміти зберігати додаткові атрибути, і самі атрибути потрібно якось поставити. Сучасні ядра всі забезпечують, але при самостійній перезібравши ядра не забудь активувати параметр "Extended attributes" в обраній файловій системі.
Атрибути встановлюються при ініціалізації системи. Звідси робимо висновок, що об'єкт уже повинен існувати на момент встановлення атрибутів. Сам атрибут включає ідентифікатор власника, роль і тип об'єкта. Причому ідентифікатор SELinux (створюється командою semanage), хоча і може збігатися в номері з UID користувача Linux (uid), але це дві різні речі. Не забуваємо ще про один важливий відміну - SELinux оперує ролями, тому кілька облікових записів Linux можуть мати одну й ту ж обліковий запис SELinux. І головне - виконання команди
Перевірити це легко:
$ Id-Z
user_u: user_t: unconfined_t
Отримуємо повноваження супер і перевіряємо знову:
$ Su
# Id-Z
user_u: user_t: unconfined_t
Якщо зайти одразу під рутом, то роль інша:
# Id-Z
root: system_r: unconfined_t: SystemLow-SystemHigh
Змінити роль можна за допомогою команди newrole. При використанні SELinux штатні команди виводять і контекст. Щоб переглянути контекст файлів і процесів, набираємо:
# Ls-l-context /
# Ps-ax-Z
Крім того, контекст можна вважати прямо з / proc:
# Ps aux | grep syslogd
root 2729 0.0 0.0 5908 624? Ss 7:30 0:00 syslogd-m 0
# Cat / proc/2729/attr/current
system_u: system_r: syslogd_t: s0
Передбачена робота SELinux в трьох режимах - disable (відключений), enforcing (політики виконуються, все, що не відповідає - блокується), permissive (політики аналізуються, всі порушення заносяться до журналу "avc: denied", але блокування не виробляються). Дізнатися поточний режим просто, як, втім, і деякі інші налаштування, досить прочитати дані з псевдофайловой системи / selinux:
$ Cat / selinux / enforce
Якщо отримаємо 1, значить, SELinux активований. Щоб змінити режим роботи на льоту, просто записуємо в цей файл 0 або 1:
# Echo 0> / selinux / enforce
Також можна скористатися утилітою "setenforce [Enforcing | Permissive | 1 | 0]".
Власне настройки проводяться в конфігураційних файлах, розміщених в каталозі / etc. У дистрибутивах, що базуються на RedHat, доступний графічний SELinux Administration Tool (system-configselinux, пакет policycoreutils-gui). Так, режим роботи встановлюється у файлі / etc / sysconfig / selinux (насправді це посилання на / etc / selinux / config). Зокрема, режим роботи визначає параметр SELINUX:
SELINUX = enforcing | permissive | disabled
За умовчанням в більшості дистрибутивів SELinux захищає не всі демони, а тільки строго певні: dhcpd, httpd, named, nscd, ntpd, portmap, snmpd, squid і syslogd. Для решти політика не визначена - unconfined_t. Щоб захистити всю систему, необхідно змінити значення SELINUXTYPE на strict:
SELINUXTYPE = targeted | strict
У каталозі / etc / selinux / targeted / contexts знаходимо опис контекстів.
Наприклад, для root контекст описується так:
# Cat / etc / selinux / targeted / contexts / users / root
system_r: unconfined_t: s0 system_r: unconfined_t: s0
system_r: initrc_t: s0 system_r: unconfined_t: s0
Щоб переглянути всі контексти, пов'язані з httpd, введи таку команду:
# Grep-iR httpd / etc / selinux / targeted / contexts
Ти побачиш, що для різних ситуацій контекст буде відрізнятися. Тепер отримаємо список всіх параметрів SELinux: "getsebool-a". Для установки використовуй команду setsebool (з ключем '-P' для збереження значення після перезавантаження) або графічну утиліту system-configsecuritylevel. Висновок "sestatus-v" покаже всі поточні установки. Не забуваємо і про журнали:
# Dmesg | grep-i selinux
SELinux: Initializing.
SELinux: Starting in permissive mode
# Grep-iR selinux / var / log / messages
Всі допоміжні утиліти SELinux зібрані в кількох пакетах: setools або policycoreutils, policycoreutils-newrole. Перший, як правило, вже встановлений в системі, інших немає. Наприклад, newrole, що дає можливість користувачеві змінити роль, доступна саме в policycoreutils. Після установки в системі присутні тільки набори політик для targened, інші набори політик завантажуються в пакетах selinux-policy *. Сорци політик для їх самостійного складання винесені в selinux-policy-devel.
Розібратися в більш ніж 200 файлах, що мають кілька тисяч рядків, врукопашну дуже важко. Автоматизувати цю задачу покликаний пітоновий скрипт audit2allow (у policycoreutils), він генерує нові політики на основі аналізу журналів і блокувань SELinux.
Проекти LIDS, GRSecurity і RSBAC
Окрім проектів, описаних у статті, в даний час розвиваються й інші, що дозволяють підвищити захист Linux-систем - LIDS (Linux Intrusion Detection System), GRSecurity і RSBAC (Rule Set Based Access Control). Коротко про них.
Проект LIDS реалізує MAC, адмін може чітко вказати дозволу для файлів і каталогів. Крім цього механізми TPE (Trusted Path Execution) і TDE (Trusted Domain Enforcement) дозволяють переконатися, що програма працює так, як призначено. Сайт проекту деякий час був занедбаний, хоча інструменти розвиваються. Управління проводиться за допомогою утиліт і чимось нагадує настроювання правил файєри.
# Lidsconf-A-o / sbin-j READONLY
GRSecurity - розробка, що охоплює кілька технологій зміцнення безпеки - MAC / ACL, покращений chroot, рандомізація TCP ISN і PID, рольова система контролю доступу RBAC, функції аудиту, захист адресного простору і стека PaX (доступний і окремо). Більшість параметрів вказується на етапі складання ядра, потім за допомогою утиліти gradm настроюються ACL.
Проект RSBAC, який реалізує мандатний і рольової механізми доступу, вже в 2000 році щосили використовувався в захищених дистрибутивах. По суті, це середовище, що дозволяє створити різні моделі доступу. Ідея заснована на публікації Маршала Абрамса і Ла Падула "Узагальнена середовище для управління доступом" (GFAC, Generalized Framework for Access Control). Крім root в ОС з'являється учетка адміністратора безпеки, який і керує доступом до інформації. Реалізовано багато цікавих функцій: відключення Linux DAC, приховування процесів, JAIL, підтримка PaX, антивірусний інтерфейс Dazuko, контроль ресурсів Linux і багато іншого. Наприклад, можна організувати доступ до файлу в певні години.
AppArmor
Технологія Application Armor спочатку розроблена Immunix Inc. Після того, як софтверний гігант Novell придбав цю компанію, код відкрили під ліцензією GNU GPL, а потім включили до складу openSUSE. Пізніше AppArmor став доступний і в інших дистрибутивах. Але коли команда Immunix покинула Novell, подальший розвиток проекту зупинилося. І хоча в тому ж openSUSE підтримка AppArmor була збережена, в дистрибутив інтегрували SELinux. У результаті почали розноситися чутки а-ля "AppArmor is dead", що в одних викликало радість, так як тепер всі зусилля можна кинути на розвиток однієї системи захисту, в інших критику - відсутність конкуренції ще ні до чого хорошого не приводило. Сьогодні апологетом цієї технології є Canonical, розробники якого не дивлячись ні на що продовжують розвиток AppArmor. Так, в останніх версіях додано механізм кешування правил, що дозволило прискорити їх завантаження. Для цих же цілей, і щоб захистити мережеві сервіси на ранньому етапі завантаження, частина профілів винесли в initramfs. І головне - в Ubuntu AppArmor прикрутили до LSM (Linux Security Modules), задіявши security_path замість vfs.
Основна ідея AppArmor полягає в тому, що система захисту не повинна бути складною і не повинна заважати. На відміну від SELinux, AppArmor не використовує розширені атрибути і не залежить від файлової системи. Доступ до ресурсів визначається на основі профілів (profiles), які прив'язані до шляху файлу або каталогу, причому самого файлу може і не бути на момент активації профілю. Профіль розробляється індивідуально під кожен додаток. Хоча в цьому є і недолік: при перенесенні файлу в SELinux за ним повністю зберігається контекст безпеки, в AppArmor - ні, але цього від нього і не вимагали. Хоча, якщо файл має два імені, і профіль блокує доступ до одного з них, є можливість працювати з іншим. Це слід враховувати. Також, якщо засобами SELinux можна передбачити кілька рівнів доступу до об'єкта для різних суб'єктів, то AppArmor цього не вміє. В даний час створені профілі для більшості популярних серверів і додатків, тому наявність активного AppArmor зазвичай непомітно, він не створює проблем. Крім того, в комплекті постачання йдуть два скрипти aa-genprof і aa-logprof, які допоможуть швидко створити профіль для нової програми. Управління AppArmor проводиться за допомогою init-скрипта, який запускає модуль ядра, ініціалізує профілі та монтує псевдофайловую систему securityfs.
$ Sudo / etc / init.d / apparmor start
Щоб переглянути список завантажених профілів, досить вважати файл / sys / kernel / security / apparmor / profiles (або запустити / etc / init.d / apparmor status): залежно від варіанту дистрибутива Server / Desktop кількість активних профілів буде по-різному. Самі профілі зберігаються у файлах (окремо для кожного додатка) в каталозі / etc / apparmor.d і всередині містять опис каталогів і окремих файлів, із зазначенням прав доступу. Також вказується робота в мережі і сумісність з іншими профілями. Для спрощення завдання використовуються регулярні вирази. За замовчуванням профілі AppArmor працюють в примусовому enforce-режимі. Коли сервіс не може вийти за рамки установок, всі спроби блокуються і фіксуються в журналі. При необхідності його можна перевести в ощадливий режим complain, коли порушення лише фіксуються. Причому, на відміну від SELinux, де режим навчання активується глобально, в AppArmor його можна включити для окремого профілю. Перекласти профіль в ощадливий режим можна трьома способами:
* Вказати у файлі профілю flags = (complain);
* Використовувати команду complain названіе_программи (повернути командою enforce);
* Або глобально командою "echo 1> / sys / kernel / security / apparmor / control / complain".
А ще профілі відключаються на льоту, перевантажуються, загалом, повна свобода дій. Власне, простота і приваблює в AppArmor адмінів, розробників і простих користувачів.
Додаткові профілі можна знайти в репозиторії дистрибутива (apt-cache search apparmor), крім того, є онлайн-банк профілів - apparmor.opensuse.org.
До слова, для ядер 2.4/2.6 існувала розробка Trustees, реалізує ACL a-ля Novell Netware, яка в зручній формі розписувала доступ до каталогів аж до вказівки окремих груп і користувачів, і не залежала від файлової системи. На жаль, проект заглох, а це була б золота середина між SELinux і AppArmor.
Збиваємо пиху з Skype
Напевно, найбільше претензій з точки зору безпеки у користувача викликає Skype. Куди тільки не лізе ця прога (див. статтю Кріса "Skype: прихована загроза"). Описувані технології як раз і дозволяють убезпечити себе. Забігаючи вперед, скажу, що користувачі вже давно нагенеріровалі профілі для більшості популярних прог, і скайп тут не виняток. Дивись, наприклад, тут: wwwcynapses.org / tmp / apparmor / usr.bin.skype. Деякі профілі зібрані в окремому пакеті - apparmor-profiles. Але профіль легко створити і самому. Для цього в комплекті йде утиліта aa-genprof (або просто genprof). Запускаємо її з вказанням виконуваного файлу як параметр:
$ Sudo aa-genprof / usr / bin / skype
Далі працюємо як завжди: дзвонимо, відсилаємо повідомлення, приймаємо файли, додаємо і видаляємо учеткі. Після закінчення перериваємо роботу в каталозі / etc / apparmor.d / usr.bin.skype. Потім перезапускаємо AppArmor або просто активуємо профіль в enforce-режимі:
$ Sudo aa-enforce skype
Всі проблеми і зауваження по роботі профілів AppArmor шукай у логах.
TOMOYO Linux
Проект TOMOYO Linux розпочато в 2003 році японською компанією NTT DATA CORPORATION як легка реалізація MAC для Linuх-ядра. Через два роки ліцензію змінили на GNU GPL та виклали код на SF.net. Деякий час проект надавав патчі і готові збірки ядер для різних дистрибутивів. Але починаючи з версії ядра 2.6.30, код TOMOYO Linux включений в основну гілку розробки, що вже саме по собі - Подія для будь-якого подібного проекту.
В даний час існує дві версії TOMOYO Linux. Перша версія використовує оригінальні хуки, вона доступна тільки у вигляді патчів і може використовуватися в ядрах 2.4 та 2.6. Друга (яка вже в ядрі) адаптована під LSM, але за функціональним можливостям поступається версії 1.х: немає підтримки мережевих функцій, обробки атрибутів, POSIX-можливостей (на сайті представлена порівняльна таблиця). В даний час відповідні пакети є в репозиторіях багатьох дистрибутивів, але фактично підтримка заявлена поки тільки в Mandriva. До речі, в цьому дистрибутиві пропонується і графічний інтерфейс Tomoyo GUI, що дозволяє запустити і налаштувати політики додатків. Доступність у репозиторіях пакетів для більшості дистрибутивів дозволяє буквально в лічені хвилини перевести ОС на нову систему безпеки. Наприклад, Ubuntu 10.04:
$ Sudo echo 'deb http://osdn.dl.sourceforge.jp/tomoyo/47128/. /'>> / Etc / apt / sources.list
$ Sudo apt-get update
$ Sudo apt-get install linux-ccs ccs-tools
Якщо ядро збирається самостійно, активуй параметр "Enable different security models" і "TOMOYO Linux Support" в секції Security options.
При першому погляді TOMOYO дуже схожий на AppArmor. Обидві системи контролюють шлях (pathname based), а правила мають подібний синтаксис. Але є й відмінності. Так, в TOMOYO можна вказати поведінку програми в залежності від того, як вона запущена. Наприклад, оболонка, запущена через SSH, може мати більше обмежень, ніж запущена з локальної системи. Передбачена перевірка додаткових параметрів, з якими включена програма, а також привілеїв (UID / GUD). Додатки в термінології TOMOYO називаються доменами (domains). Файли TOMOYO перебувають у каталозі / etc / tomoyo, після запуску системи настройки мають своє відображення в / proc / tomoyo, де їх можна редагувати на льоту. Параметри роботи TOMOYO зберігаються в / etc / tomoyo / profile.conf і доступні в / proc / tomoyo / profile. Саме тут визначаються режими роботи TOMOYO - disable, permissive, enforsing і learning (навчаючись, система сама будує правила). Є й інші файли:
* Manager.conf (/ proc / tomoyo / manager) - програми, які можуть змінити політику в / proc / tomoyo;
* Exception_policy.conf (/ proc / tomoyo / exception_policy) - виключення для політик домену;
* Domain_policy.conf (/ proc / tomoyo / domain_policy) - політики домену;
* Meminfo.conf (/ proc / tomoyo / meminfo) - налаштування використання пам'яті і квот.
Після установки пакета ccs-tools необхідно провести ініціалізацію TOMOYO, виконавши скрипт / usr / lib / ccs / tomoyo_init_police.sh, який і створить потрібні конфіги. Далі буде потрібно перезавантаження системи. Потім можна запускати редактор політик:
# / Usr / lib / ccs / editpolicy / etc / tomoyo /
Ще одна важлива риса - TOMOYO може працювати паралельно з SELinux і AppArmor.