🥇Системи за защита на Linux

Една от причините за грандиозния успех на Linux ОС в вградените, мобилни устройства и сървъри е значителната степен на безопасност на ядрото, придружаващите услуги и приложения. Но ако внимателно разгледате архитектурата на ядрото на Linux, няма как да намерите квадратче, отговарящо за безопасността, както такава. Къде се крие подсистемата за безопасност на Linux и от какво се състои тя?

Предистория на Linux Security Modules и SELinux

Security Enhanced Linux представлява набор от правила и механизми за достъп, основан на моделите на задължителен и ролеви достъп, за защита на системите Linux от потенциални заплахи и коригиране на недостатъците на Discretionary Access Control (DAC) — традиционната система за безопасност в Unix. Проектът е започнат в недрата на Агенцията за национална сигурност на САЩ, като основната разработка е извършвана предимно от подизпълнители на Secure Computing Corporation и MITRE, а също така от редица изследователски лаборатории.

Linux Security Modules

Линус Торвалдс е направил редица забележки относно новите разработки на АНБ, за да могат да бъдат включени в основната линия на ядрото на Linux. Той описва обща среда, с набор от улавящи функции за управление на операциите с обекти и набор от защитни полета в структури от данни на ядрото за съхраняване на съответните атрибути. След това тази среда може да се използва от зареждаеми модули на ядрото за реализиране на желан модел за безопасност. LSM е напълно интегриран в ядрото на Linux v2.6 през 2003 година.

Фреймворкът LSM включва защитни полета в структури от данни и извиквания на улавящи функции в критични точки от кода на ядрото за управление на тях и извършване на контрол на достъпа. Той също така добавя функции за регистрация на модули за безопасност. Интерфейсът /sys/kernel/security/lsm съдържа списък на активни модули в системата. Хуките LSM се съхраняват в списъци, които се извикват по реда, указан в CONFIG_LSM. Подробна документация за хуковете е включена в заглавния файл include/linux/lsm_hooks.h.

Подсистемата LSM позволи пълно интегриране на SELinux от същата версия на стабилното ядро Linux v2.6. Буквално веднага SELinux стана де факто стандарт в защитената среда на Linux и беше включен в най-популярните дистрибуции: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Глосарий на SELinux

Идентичност — Потребителят SELinux не е същият като обичайния Unix/Linux потребителски идентификатор; те могат да съществуват на една и съща система, но по същността си са напълно различни. Всяка стандартна Linux акаунт може да отговаря на един или повече в SELinux. Идентичността на SELinux е част от общия контекст за сигурност, който определя в кои домейни е разрешено влизането и в кои — не.
Домейни — В SELinux домейнът е контекстът на изпълнението на субекта, т. е. процеса. Доменът пряко определя достъпа, който има процесът. Доменът е основно списък на действията, които процесите могат да извършват или какви действия може да извършва процесът с различни типове. Някои примери за домейни: sysadm_t за системно администриране и user_t, който е обикновен непривилегиран домейн на потребителя. Инициализационната система init работи в домейна init_t, а процесът named работи в домейна named_t.
Роли — Това, което служи като посредник между домейните и потребителите на SELinux. Ролите определят в какви домейни може да бъде потребителят и до какви типове обекти може да получи достъп. Подобен механизъм за разделяне на достъпа предотвратява заплахата от повишаване на привилегиите. Ролите са вписани в модела за сигурност Role Based Access Control (RBAC), използван в SELinux.
Типове — Атрибут на списъка Type Enforcement, който се прилага на обект и определя кой ще има достъп до него. Похоже на определението за домейн, с изключение на това, че домейнът се прилага на процеса, а типът — за обекти като директории, файлове, сокети и др.
Субекти и обекти — Процесите са субекти и работят в определен контекст или домейн за сигурност. Ресурсите на операционната система: файлове, директории, сокети и т.н. са обекти, на които се присвоява определен тип, или иначе казано — ниво на секретност.
Политики SELinux — За защитата на системата SELinux използва разнообразни политики. Политиката на SELinux определя достъпа на потребителите до роли, ролите — до домейни и домейните — до типове. В началото потребителят се авторизира да получи роля, след което ролята се авторизира за достъп до домейни. Накрая домейнът може да има достъп само до някои типове обекти.

LSM и архитектура SELinux

Въпреки че наименованието LSM всъщност не са зареждаеми модули на Linux, подобно на SELinux, той е интегриран директно в ядрото. Всяка промяна в изходния код на LSM изисква ново компилиране на ядрото. Съответната опция трябва да бъде включена в настройките на ядрото, иначе кодът на LSM няма да бъде активиран след зареждане. Но дори и в този случай, той може да бъде включен чрез опцията на зареждача на ОС.

Стек от проверки LSM

LSM е оборудван с хукове в основните функции на ядрото, които могат да бъдат релевантни за проверките. Една от основните характеристики на LSM е, че те са организирани по принципа на стек. Така стандартните проверки все още се извършват и всеки слой на LSM добавя допълнителни елементи за управление и контрол. Това означава, че забраната не може да бъде отменена. Както е показано на изображението, ако резултатът от рутинните DAC проверки е отказ, то дори не стига до хуките на LSM.

SELinux е наследил архитектурата за сигурност Flask на изследователската операционна система Fluke, в частност принципа на най-малките привилегии. Същността на тази концепция, както подсказва името, е да предостави на потребителя или процеса само онези права, които са необходими за извършване на предвидените действия. Този принцип е реализиран чрез принудително типизиране на достъпа, така че контролът на достъпа в SELinux е базиран на модела домейн => тип.

Благодарение на принудителното типизиране на достъпа, SELinux има много по-забележителни възможности за разграничаване на достъпа в сравнение с традиционния DAC модел, използван в ОС Unix/Linux. Например, може да се ограничи номерът на мрежовия порт, на който ще слуша FTP сървърът, да се разреши запис и промяна на файлове в определена папка, но не и тяхното изтриване.

Основните компоненти на SELinux са:

Сървър за прилагане на политики — Основният механизъм за организация на контрола на достъпа.
База данни с политики за сигурност на системата.
Взаимодействие с хук за събития LSM.
Selinuxfs — Псевдо-файлова система, подобна на /proc, монтирана в /sys/fs/selinux. Динамично се запълва от ядрото на Linux по време на изпълнение и съдържа файлове с информация за статуса на SELinux.
Кеш за достъпните вектори — Помощен механизъм за увеличаване на производителността.

Схема на работа на SELinux

Всичко това работи по следния начин.

Определен субьект, в терминах SELinux, который выполняет разрешенное действие над объектом после проверки DAC, как показано на верхней картинке. Этот запрос на выполнение операции передается к перехватчику событий LSM.
Оттуда запрос, вместе с контекстом безопасности субьекта и объекта, передается в модуль SELinux Abstraction and Hook Logic, который отвечает за взаимодействие с LSM.
Экземпляр принятия решения о доступе субьекта к объекту называется Policy Enforcement Server, и к нему поступают данные от SELinux AnHL.
Для принятия решения о доступе или запрете Policy Enforcement Server обращается к подсистеме кэширования наиболее часто используемых правил Access Vector Cache (AVC).
Если решение для данного правила не найдено в кэше, запрос передается дальше в базу данных политик безопасности.
Результат поиска из базы данных и AVC возвращается в Policy Enforcement Server.
Если найденная политика соответствует запрашиваемому действию, операция разрешается. В противном случае операция запрещается.

Управление настройками SELinux

SELinux работает в одном из трех режимов:

Enforcing — Строгое соблюдение политик безопасности.
Permissive — Допускается нарушение ограничений, в журнале фиксируется соответствующая пометка.
Disabled — Политики безопасности не действуют.

Узнать в каком режиме находится SELinux можно следующей командой.

[admin@server ~]$ getenforce
Permissive

Изменение режима до перезагрузки, например, выставить на enforcing, или 1. Параметру permissive соответствует числовой код 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #то же самое

Также изменить режим можно редактированием файла:

[admin@server ~]$ cat /etc/selinux/config

# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=изпълняващ # SELINUXTYPE= can take one of three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection.
SELINUXTYPE=targete

Разница с setenfoce в том, что при загрузке операционной системы режим SELinux будет установлен в соответствии со значением параметра SELINUX в конфигурационном файле. Кроме того, изменения enforcing disabled вступают в силу только через редактирование файла /etc/selinux/config и после перезагрузки.

Просмотр краткого статусного отчета:

[admin@server ~]$ sestatus

Статус на SELinux: активен Монтиране на SELinuxfs: /sys/fs/selinux Коренна директория на SELinux: /etc/selinux Заредено име на политика: целенасочена Текущ режим: разрешителен Режим от конфигурационен файл: задължителен Статус на политика MLS: активен Статус на политика deny_unknown: разрешен Максимална версия на ядрената политика: 31
Для просмотра атрибутов SELinux некоторые стандартные утилиты используют параметр -Z.

[admin@server ~]$ ls -lZ /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200920
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200927
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201004
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201011
[admin@server ~]$ ps -u apache -Z
LABEL                             PID TTY          TIME CMD
system_u:system_r:httpd_t:s0     2914 ?        00:00:04 httpd
system_u:system_r:httpd_t:s0     2915 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2916 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2917 ?        00:00:00 httpd
...
system_u:system_r:httpd_t:s0     2918 ?        00:00:00 httpd

В сравнение с обикновеното извеждане на ls -l тук има няколко допълнителни полета в следния формат:

:::

Последното поле обозначава нещо подобно на етикет за секретност и се състои от комбинация от два елемента:

s0 — значение, също така записват интервал lowlevel-highlevel
c0, c1… c1023 — категория.

Промяна на конфигурацията на достъпите

Използвайте semodule, за да зареждате модули SELinux, да добавяте и премахвате такива.

[admin@server ~]$ semodule -l |wc -l #списък на всички модули
408
[admin@server ~]$ semodule -e abrt #enable - активиране на модула
[admin@server ~]$ semodule -d accountsd #disable - деактивиране на модула
[admin@server ~]$ semodule -r avahi #remove - премахване на модула

Първата команда semanage login свързва потребителя на SELinux с потребителя на операционната система, втората извежда списък. Накрая последната команда с ключа -r премахва свързването на потребителите на SELinux с акаунти на ОС. Обяснението на синтаксиса на стойностите MLS/MCS Range е в предишния раздел.

[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l

Име на вход SELinux потребител MLS/MCS обхват услуга __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 * [admin@server ~]$ semanage login -d karol
Екип semanage user се използва за управление на свързаностите между потребителите и ролите на SELinux.

[admin@server ~]$ semanage user -l
                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range             SELinux Roles
guest_u         user       s0         s0                    guest_r
staff_u         staff      s0         s0-s0:c0.c1023        staff_r sysadm_r
...
user_u          user       s0         s0                    user_r
xguest_u        user       s0         s0                    xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_u

Параметрите на командата:

-a добави потребителска записка за свързаност на роли;
-l списък на свързаностите между потребители и роли;
-d премахни потребителска записка за свързаност на роли;
-R списък на ролите, прикрепени към потребителя;

Файлове, портове и булеви стойности

Все модули SELinux предоставят набор правил для маркировки файлов, но также можно добавить собственные правила в случае необходимости. Например, мы желаем предоставить веб-серверу доступ к папке /srv/www.

[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(\/.*)?
[admin@server ~]$ restorecon -R /srv/www/

Первая команда регистрирует новые правила маркировки, а вторая сбрасывает или устанавливает типы файлов в соответствии с текущими правилами.

Аналогично, TCP/UDP порты отмечаются так, что лишь соответствующие сервисы могут их прослушивать. Например, чтобы веб-сервер мог прослушивать порт 8080, нужно выполнить команду.

[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080

Значительное число модулей SELinux имеют параметры, которые могут принимать булевы значения. Весь список таких параметров можно увидеть с помощью getsebool -a. Изменять булевы значения можно с помощью setsebool.

[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_cgi --> on
[admin@server ~]$ setsebool -P httpd_enable_cgi off
[admin@server ~]$ getsebool httpd_enable_homedirs --> off

Практика, доступ к интерфейсу Pgadmin-web

Рассмотрим практический пример: мы установили на RHEL 7.6 pgadmin4-web для администрирования БД PostgreSQL. Мы прошли небольшой квест с настройкой pg_hba.conf, postgresql.conf и config_local.py, выставили права на папки, установили недостающие модули Python через pip. Все готово, запускаем и получаем 500 Внутренняя ошибка сервера.

Начнем с типичных подозреваемых, проверяем /var/log/httpd/error_log. Там есть некоторые интересные записи.

[timestamp] [core:notice] [pid 23689] Политиката на SELinux е активирана; httpd работи в контекст system_u:system_r:httpd_t:s0 ... [timestamp] [wsgi:error] [pid 23690] [Errno 13] Достъп отказан: '\/var\/lib\/pgadmin' [timestamp] [wsgi:error] [pid 23690] [timestamp] [wsgi:error] [pid 23690] СЪВЕТ: Може да се наложи ръчно да зададете правата на [timestamp] [wsgi:error] [pid 23690] \/var\/lib\/pgadmin, за да позволите на apache да записва в него.

На этом этапе у большинства администраторов Linux возникнет стойкое искушение запустить setenforce 0 и закончить дело. Признаюсь, в первый раз я так и сделал. Это, конечно, тоже выход, но далеко не самый лучший.

Несмотря на громоздкость конструкций, SELinux может быть дружелюбным к пользователю. Достаточно установить пакет setroubleshoot и просмотреть системный журнал.

[admin@server ~]$ yum install setroubleshoot [admin@server ~]$ journalctl -b -0 [admin@server ~]$ service restart auditd

Обратите внимание на то, что сервис auditd необходимо перезапускать именно так, а не с помощью systemctl, несмотря на наличие systemd в ОС. В системном журнале будет указано не только факт блокировки, но также причина и способ преодоления запрета..

Выполняем эти команды: