Стандартная модель UNIX представляет из себя форму "избирательного контроля доступа" (DAC - Discretionary Access Control), поскольку позволяет владельцам контролируемых объектов устанавливать права на них. Пользователь сам может разрешить другим просмотр содержимого домашнего каталога или написать программу с флагом `setuid`, которая позволит другим пользователям отправлять сигналы его процессам.
Системы мандатного управления доступом (MAC, Mandatory Access Control) позволяют администраторам писать политики контроля доступа, которые переопределяют или дополняют избирательные разрешения традиционной модели. Например, вы можете установить правило, согласно которому домашние каталоги доступны только их владельцам. Это может помочь сохранить конфиденциальные документы, даже если пользователь небрежно относится к его разрешениям. Хотя такие системы разрабатывались для реализации многоуровневой безопасности в государственных организациях с различными грифами секретности, на практике чаще всего вы сталкнётесь с её применением для защиты фоновых служб. Хорошо реализованные политики могут помешать компрометации системы с уязвимым программным обеспечением.
SELinux - одна из старейших реализаций системы MAC для Linux, разработанная в Агентством национальной безопасности США. Система реализует почти все возможности MAC и RBAC (Role Based Access Control). Из-за этого разработка политик является сложной задачей. К счастью, многие общие политики доступны онлайн и имеют разумные значениям по умолчанию. Для упрощения разработки политик могут использоваться специализированные редакторы, например https://seedit.sourceforge.net/.
### 2.1 Изучим установленные контексты безопасности
Для начала давайте проверим контекст файла в домашнем каталоге пользователя `stud`:
```
$ cd
$ touch file
$ ls -Z
```
Флаг `-Z` присутствует в широком спектре распространенных инструментов CLI, включая `ls` и `ps`. При указании этого флага в дополнении к стандартным разрешениям UNIX, информации о пользователе и группе отображается контекст SELinux файла.
@ -58,14 +65,16 @@ $ ls -Z
Пользователь SELinux отличается от пользователя UNIX и существует исключительно для того, чтобы связать пользователя UNIX с набором ролей. Это позволяет пользователям UNIX быть ограниченными политикой SELinux.
В нашем случае пользователь `unconfined_u` означает, что пользователь сопоставлен слогином SELinux по умолчанию. Это означает, что пользователю разрешено запускать любое приложение, разрешенное стандартными разрешениями файловой системы. Однако, если приложение может перейти в другой домен, к нему будут применятся ограничения, задаваемые SELinux.
В нашем случае пользователь `unconfined_u` означает, что пользователь сопоставлен спользователем SELinux по умолчанию. Это означает, что пользователю разрешено запускать любое приложение, разрешенное стандартными разрешениями файловой системы. Однако, если приложение может перейти в другой домен, к нему будут применятся ограничения, задаваемые SELinux.
Список пользователей SELinux в системы можно посмотреть командами:
```
$ seinfo -u
$ semanage login -l
```
Cписок сопоставлений между учетными записями пользователей SELinux и Linux
```
# semanage login -l
```
### 2.2 Переход в другой домен
Чтобы продемонстрировать разницу между процессами c ограничениями и без, давайте запустим приложение, которого переход в другой домен не определён:
@ -73,7 +82,18 @@ $ semanage login -l
# yes >/dev/null &
# ps -Z | grep yes
```
Процесс `yes` помечен доменом `unconfined_t`, что указывает на то, что он по-прежнему обладает полными привилегиями `root` и может делать всё, что пожелает.
Дадим расшифровку вывода selinux метки процесса.
```
<user>:<role>:<type>:<secrecy_level>:optional
```
- Вначале выводится идентификатор пользователя SELinux `unconfined_u`.
- Частью SELinux является модель безопасности управления доступом на основе ролей (RBAC). Пользователи SELinux авторизованы для ролей, а роли авторизованы для доменов. Роль служит посредником между доменами и пользователями SELinux. Роли, которые можно ввести, определяют, в какие домены можно войти; в конечном итоге это определяет, к каким типам объектов можно получить доступ. Модель ролей помогает лучше отразить требования к безопасности и тем самым снизить уязвимость к атакам. В данном случае выводится роль `unconfined_r`.
- Метка типа `unconfined_t` является атрибутом Type Enforcement. Тип определяет домен для процессов и тип для файлов. Правила политики SELinux определяют, как типы могут получать доступ друг к другу, будь то домен, обращающийся к типу, или домен, обращающийся к другому домену. Доступ разрешен только в том случае, если существует определенное правило политики SELinux, которое разрешает это.
- Уровень (секретности) является атрибутом MLS (Multi-Level Security, модель Bell-La Padula) и MCS (Multi-Category Security). Диапазон MLS представляет собой пару уровней, записываемую как `lowlevel-highlevel`, если уровни различаются. Если уровни идентичны `s0-s0` может записываться одним значением `s0`.
- В опциональном поле отображаются категории, которые не являются обязательными. Если есть категории, уровень записывается как `уровень: набор категорий`. Если категорий нет, пишется как `уровень`. Если набор категорий представляет собой непрерывную серию, его можно сократить. Например, `c0.c3`— это то же самое, что `c0,c1,c2,c3`. Файл `/etc/selinux/default/setrans.conf` отображает уровни (`s0:c0`) в удобочитаемую форму (то есть `CompanyConfidential`).
Итак, процесс `yes` помечен доменом `unconfined_t`, что указывает на то, что он по-прежнему обладает полными привилегиями `root` и может делать всё, что пожелает.
Мы увидим другую картину для процесса `auditd`:
```
@ -81,7 +101,7 @@ $ semanage login -l
```
Обратите внимание, что третье поле - `auditd_t`, означающее, что процесс `auditd` был ограничен доменом `auditd_t`.
Остановим запущенный фоновые процессы`yes` и двинемся дальше.
Остановим запущенный фоновый процесс`yes` и двинемся дальше.
Следующее правило гласит, что когда процесс в домене `initrc_t` запускает файл типа `acct_exec_t`, домен процесса должен быть изменен на `acct_t`, если это разрешено политикой. Чтобы это правило перехода домена работало, нужно также присутствие нескольких разрешений.
allow initrc_t acct_exec_t:file execute; # Разрешение на запуск файла типа acct_exec_t в исходном домене initrc_t
allow acct_t acct_exec_t:file entrypoint; # Разрешение на наличие точки входа файла типа acct_exec_t в домен целевой домен acct_t
allow initrc_t acct_t:process transition; # Разрешение процессу на переход в домен целевой acct_t
# Разрешение на запуск файла типа acct_exec_t в исходном домене initrc_t
allow initrc_t acct_exec_t:file execute;
# Разрешение процессу на переход в домен целевой acct_t
allow initrc_t acct_t:process transition;
# Разрешение на наличие точки входа файла типа acct_exec_t в домен целевой домен acct_t
allow acct_t acct_exec_t:file entrypoint;
```
Подробнее в документации правила https://selinuxproject.org/page/TypeRules.
Обычно в политиках используют макрос `domtrans_pattern` или `domain_transition_pattern` определённый в `/usr/share/selinux/devel/include/support/misc_patterns.spt` для указания правила перехода и разрешений вместе.
### 2.3 Полезная утилита - restorecon
Если и есть, что посоветовать запомнить новому пользователю SELinux, так это `restorecon`. Restorecon приведет контекст SELinux к тому, что определено в базе данных контекста системы.
Если и есть, что посоветовать запомнить новому пользователю SELinux, так это `restorecon`. Restorecon приведет контекст SELinux к тому, который определен в базе данных контекста системы.
Чтобы попробовать, давайте намеренно неправильно установим контекст в примере SELinux AVC log:
Чтобы попробовать, давайте намеренно неправильно установим контекст:
```
# touch testaudit
# ls -Z ./testaudit
system_u:object_r:admin_home_t:s0 ./testaudit
# chcon -t httpd_sys_content_t ./testaudit
@ -125,17 +151,17 @@ Relabeled /root/testaudit from system_u:object_r:httpd_sys_content_t:s0 to syste
```
Выше также применяется `chcon`, которой вы можете временного изменить контекст файла.
Установка контекст на `httpd_sys_content_t` также устранила бы проблему, о которой сообщалось в нашем тестовом AVC.
## 3. Установка тестового сервиса
Подготовим сервис, для которого далее будем писать собственную политику безопасности SELinux.
Скачайте текущий репозиторий и перейдите в папку `linux_tasks/modeul2/test_service`.
Скачайте текущий репозиторий и перейдите в папку `linux_tasks/module2/02_mac_selinux/test_service`.
Настройте окружение разработчика, скачайте необходимые заголовочные файлы и установите сервис `testapp`с помощью `make`:
- `testapp.te` - это базовая политика для приложения. Он устанавливает правила для домена `testapp_t`,
- `testapp.if` - это файл интерфейса. Интерфейсы подобны общедоступным функциям в том смысле, что они предоставляют другим модулям SELinux способы взаимодействия с тем, который вы пишете,
- `testapp.fc` - это файл контекстов. Он содержит информацию о маркировке всех объектов файловой системы, на которые ссылается политика,
- `testapp.sh` это предоставленный Red Hat скрипт, который компилирует и загружает модуль политики SELinux.
- `testapp.sh` это скрипт, который компилирует и загружает модуль политики SELinux.
### 4.2. Скомпилируйте и загрузите политику
@ -212,6 +238,8 @@ Created the following files:
$ sudo ./testapp.sh
```
Примечание. Заменити в файле .te `pid` на `runtime` в макросах `files_*`.
Первые 9 строк выходных данных показывают компиляцию политики, загрузку политики в память и автоматическое создание справочной страницы для политики:
### 4.4. Как приложение в конечном итоге получает testapp_context?
Это связано с правилами перехода домена SELinux. Служба `testapp` запускается `systemd`, которая запускается с контекстом `init_t`, поскольку это наша служба инициализации. Из-за правил перехода он изменяет контексты при запуске службы.
type_transition init_t testapp_exec_t : process testapp_t;
```
Правило гласит, что когда любой процесс, помеченный как `init_t`, выполняет любой двоичный файл, помеченный как `testapp_exec_t`, вновь созданный процесс будет помечен как `testapp_t`.
Правило гласит, что когда любой процесс, помеченный как `init_t`, выполняет любой ,исполняемый файл, помеченный как `testapp_exec_t`, вновь созданный процесс будет помечен как `testapp_t`.
На данный момент у нас есть общая политика для приложения `testapp`, которая настроена на разрешающий режим. Таким образом, приложение может запускаться, и SELinux будет генерировать предупреждения при нарушении существующей системной политики, но не будет предпринимать никаких действий.
@ -308,7 +336,7 @@ type=AVC msg=audit(1552588580.764:25971): avc: denied { read } for pid=1022 c
Если мы внимательно посмотрим на них, то увидим, что процессу тестового приложения отказано в открытии в `/proc/meminfo` и в чтении в `/proc` в целом. Итак, нам нужно найти интерфейс, который позволит осуществлять эти доступы, и добавить его в наш файл `testapp.te`.
### 6.2 Найдите правильный интерфейс
Определения интерфейса SELinux находятся в `/usr/share/selinux/devel/include`, если вы устанавливаете пакет `selinux-policy-devel`. Если мы ищем `/proc`, в файлах с именем `*.if` (определения интерфейса):
Определения интерфейса SELinux находятся в `/usr/share/selinux/devel/include`, если вы установили пакет `selinux-policy-devel`. Если мы ищем `/proc`, в файлах с именем `*.if` (определения интерфейса):
```
$ cd /usr/share/selinux/devel/include
$ find . -type f -name "*.if" -exec grep -H '/proc' {} \; | grep "system state information"
@ -945,6 +973,7 @@ setsebool –P httpd_enable_homedirs on
