Linux. Как работает hardening
Статья расскажет о том, как с помощью kconfig hardened check можно проверить настройку механизмов защиты ядра ОС Linux, которые используются для противодействия эксплойтам. На сегодняшний день данный инструмент, пожалуй, является одним из самых опасных инструментов нарушения разграничения доступа и функционирования ОС. Рассмотрим, какие основные параметры компиляции ядра и модули безопасности есть в официальном репозитории, а также попробуем выяснить, какие наборы механизмов применяются в различных дистрибутивах.
Инструменты и источники для проведения исследования
Исследование ОС Linux будем традиционно проводить на базе исходного кода, который доступен в официальном репозитории. В качестве инструментов исследования будем использовать:
Python в этом случае необходим для построение иерархии директорий, которые содержат исходный код. Именно этот метод верхнеуровневого представления будет использован как основной для исследования.
Подсистемы защиты
Головная боль любой ОС — разграничение доступа и уязвимости, которые приводят к повреждению памяти. Исторически сложилось так, что для создания ОС используются языки программирования, которые имеют определенные проблемы при неверной обработке памяти.
В ОС Linux с точки зрения защиты от различных атак на разграничение доступа и эксплуатацию уязвимостей используют следующие механизмы:
- LSM фреймворк — механизм перехвата системных функций для обработки расширениями ядра Linux;
- KASLR — рандомизация адресного пространства ядра;
- HW-Vuln — митигации и патчи, которые используются против Hardware уязвимостей (Meltdown, Spectre, и т.д.);
- Параметризация сборки и запуска ядра. Большое количество работающих алгоритмов в ядре — это потенциальный вектор для атаки, поэтому здесь исходят из минимально необходимого функционала, который можно оставить и при этом максимально уменьшить возможности проведения атак.
Большая часть механизмов противодействия атакам на разграничение доступа и эксплуатации уязвимостей находится в разделе linux/security :
Здесь в явном виде представлены модули ядра, которые можно использовать для улучшения механизмов защиты. Есть только маленькая неприятность — некоторые модули из этой директории не могут быть совместимы. На сегодняшний день, к сожалению, нет метода использования сразу несколько модулей LSM. Поэтому предполагается, что тот, кто хочет собрать себе ядро для своей ОС, должен самостоятельно решить, что за модуль ему подойдет больше. Всего их 11 штук:
Например, модуль tomoyo нельзя использовать с другими модулями.
В директории «security» есть описания для защит от различных техник, которые позволяют проводить эксплуатацию уязвимостей. Например — min_addr . Этот механизм защиты, который резервирует адреса в оперативной памяти, которые находятся рядом с нулевым адресом. Сделано это для того, чтобы нельзя было использовать начальные страницы в оперативной памяти для хранения данных эксплойта. Часть остальных «противодействий» в ядре запускается только с использованием дополнительных опций запуска ядра и компиляции. Обнаружить эти данные можно в hardening конфиге. Вся информация предоставляется только как описание отдельных параметров.
Выходит, что механизмы есть, но на выбор нужно собирать себе обойму самостоятельно. Это не удивительно, так как ядро Linux предоставляется для большого количества дистрибутивов, и поэтому разработчики отдельных дистрибутивов должны заниматься более тонкой настройкой. Давайте попытаемся выяснить, а что работает в конкретных дистрибутивах.
Ubuntu и его механизмы защиты
Популярный дистрибутив, который используется и как сервер, и для десктопов. Проверять будем с помощью вот этого инструмента — kconfig hardened check . Инструмент проверяет текущую настройку ядра с точки зрения безопасности и демонстрирует, какие параметры были установлены при установке системы. Репозиторий постоянно обновляется, поэтому список подсистем защит и параметров компиляции ядра намного больше того, что мы смогли обнаружить при исследовании исходного кода. Репозиторий предоставляет скрипт на Python для проверки опций в уже собранном дистрибутиве. Стоит отметить, что без использования эталонного конфига, инструмент показывает информацию по дистрибутиву, не указывая, что есть. Он показывает, что желательно бы иметь в качестве установленных параметров. Запускать проверку можно так:
kconfig-hardened-check -p X86_64 -c kspp-recommendations-x86-64.config
Вообще в репозитории есть 2 вида конфигов — обычный, который создан для конкретного дистрибутива, и рекомендуемый с точки зрения наибольшего количества безопасных опций. Ресурс kernsec характеризует KSSP конфиг как наиболее параноидальный с точки зрения количества применяемых параметоров. Результат для Ubuntu Server 20.04:
29 опций, которые не используются или не найдены из 111. Не такой уж плохой результат. Особенно если учесть, что конфиг эталона — параноидальный.
Debian и его механизмы защиты
Для исследования Debian был выбран неофициальный дистрибутив Debian, а его модификация — Kali Linux. Этот дистрибутив, который используют для тестирования на проникновение, посмотрим что у него у самого с параметрами безопасности:
Дистрибутив несмотря на то, что используется для узкого спектра задач все же содержит в себе достаточное количество опций и параметров ядра для противодействия атакам.
Таким образом можно выяснять, как настроен тот дистрибутив, которым вы пользуетесь на базе ядра ОС Linux.
Прямо сейчас в OTUS открыт набор на новый поток курса «Administrator Linux. Basic», Приглашаем всех желающих на бесплатный вебинар, в рамках которого наши эксперты подробно расскажут о курсе, процессе обучения, а также карьерных перспективах в данной сфере.
Записаться на вебинар.
Механизмы безопасности в Linux: краткий ликбез
В одной из прошлых статей мы рассматривали общие советы по безопасности Linux-систем. Сегодня проведём краткий экскурс в наиболее распространённые средства и инструменты, связанные с безопасностью Linux.
Информация предоставлена в весьма сжатом виде, и если какое-то средство вас заинтересует, можно пройтись в интернете по интересующим темам и прочитать более подробно.
В сегодняшней публикации мы рассмотрим POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более, что это отдельная и обширная тема.
1. POSIX ACL
Описание: разграничение прав доступа к файлам на основе их атрибутов (Discretionary Access Control, DAC).
Механизм работы: Система (в частности, менеджер файловой системы) считывает атрибуты файла, к которому обращается пользователь (или программа, работающая от имени какого-либо пользователя), после чего решает, предоставлять ли доступ на основе этих атрибутов. При ошибке доступа приложению возвращается соответствующий код ошибки.
Пример использования: чтобы запретить/разрешить доступ остальных пользователей к своему файлу, можно поменять его атрибуты через chmod, и поменять владельца/группу через chown и chgrp (либо использовать более общую команду setfacl). Текущие права доступа можно посмотреть через ls и getfacl.
2. Sudo
Описание: выполнение программ от своего и/или чужого имени.
Механизм работы: при вызове команды sudo/sudoedit система считывает файл /etc/sudoers и на его основе определяет, какие команды может вызывать пользователь.
Пример использования: вся конфигурация определяется в файле /etc/sudoers. Например, можно разрешать выполнять только определённые команды и только от определенного пользователя:
WEBMASTERS www = (www) ALL, (root) /usr/bin/su wwwДанная строчка говорит о том, что пользователи, определённые в алиасе WEBMASTERS, могут выполнять все команды от имени пользователя www, или делать su только в www.
3. Chroot
Описание: операция, ограничивающая доступ процесса к файловой системе, изменяя её корень в контексте процесса.
Механизм работы: запускает программу (по умолчанию /bin/sh) с контекстом, в котором переопределён корневой каталог файловой системы. Теперь все обращения вызванной программы не могут выйти за пределы корневого каталога (т. е. программа работает в весьма условной «песочнице»). Обойти данный механизм не составляет труда, особенно из под рута, так что это средство не рекомендуется для обеспечения безопасности. Настоящую песочницу сможет обеспечить только виртуализация.
Пример использования: создаётся специальный каталог, в него копируется необходимое для работы окружение (также можно использовать команду mount --bind ). Далее делается chroot на этот каталог, и запущенная программа работает только с предварительно подготовленным окружением. Для упрощения можно использовать различные jail-инструменты, доступные в дистрибутивах.
4. PAM
Описание: подключаемые модули аутентификации.
Механизм работы: программы, написанные с использованием PAM, обращаются к его библиотеке, которая уже собственно проводит процедуру аутентификации пользователя. При ошибке авторизации приложению возвращается соответствующий код ошибки.
Пример использования: PostgreSQL, Apache, Squid и другие программы (включая написанные вами) могут работать с учётными записями пользователей не через собственные конфигурационные файлы, а обращаться к PAM, тем самым обеспечивая различные варианты аутентификации — Kerberos, eTokens, биометрия и др. Естественно, это касается и самого Linux-а — можно входить не только вбивая пару логин/пароль.
5. SELinux
Описание: реализация системы принудительного контроля доступа (Mandatory Access Control, MAC), основанная на политиках и контекстах безопасности.
Контроль называется принудительным, когда применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа.
Механизм работы: для проверки прав доступа используется LSM-модуль ядра, который проверяет политику безопасности приложения и сверяет его тип с контекстом безопасности используемых файлов (объектов). При ошибке доступа соответствующая запись добавляется в /var/log/audit/audit.log. Пользователь может получить нотификацию об этом через утилиту setroubleshoot.
Пример использования: в targeted-режиме SELinux позволяет апачу читать только определённые каталоги. Стандартный (для кого-то) путь сделать веб-сайт в домашнем каталоге и открыть его через симлинк в /var/www не пройдёт процедуру проверки, т. к. SELinux проверяет контекст безопасности файлов, делая полное сканирование. Чтобы поменять контекст безопасности файла, необходимо использовать команду chcon (в данном случае, chcon -R -h -t httpd_sys_content_t /path/to/directory ). Текущие контексты безопасности можно посмотреть через ls -Z.
6. AppArmor
Описание: система упреждающей защиты, основанная на политиках безопасности (профилях).
Механизм работы: для проверки прав доступа используется LSM-модуль ядра, который при запуске приложения проверяет наличие его профиля (/etc/apparmor.d), и если профиль существует, то ограничивает выполнение системных вызовов в соответствии с профилем. При ошибке доступа соответствующая запись добавляется в /var/log/audit/audit.log. Пользователь может получить нотификацию об этом через утилиту apparmor-notify.
Пример использования: с помощью команды aa-genprof можно создать профиль интересующего приложения, отработав в нем все необходимые use-case-ы. Далее полученный файл профиля можно модифицировать интересующим вас образом, сохранить в /etc/apparmor.d и активировать через aa-enforce .
7. PolicyKit
Описание: Средство контроля системных привилегий.
Механизм работы: при обращении приложения к сервису (любое обращение проходит как action), он проверяет через PolicyKit права доступа пользователя для данного action-а. В зависимости от политик доступ может быть запрещен, разрешён или требовать аутентификации. Отображение ошибок (или запрос пароля) должно на себя брать клиентское приложение.
Пример использования: Ubuntu при настройке сети позволяет просматривать всю информацию без запроса пароля (т. к. конфигурация PolicyKit разрешает чтение без авторизации), но когда необходимо настройки сохранить, то запрашивается пароль. Причем пользователю не даются рутовские права на всю систему, т. к. он работает только в пределах используемого сервиса.
Заключение
Естественно, есть и другие средства, связанные с безопасностью, не рассмотренные в данной статье. Однако всё вышеперечисленное является стандартом де-факто для наиболее распространенных дистрибутивов, и если вы заботитесь о безопасности, желательно их знать.
