Мандатное разграничение доступа в Astra Linux: первые грабли админа

MAATRIX

Если вы годами администрировали Ubuntu или Debian и привыкли, что владелец файла может делать с ним что угодно, первое знакомство с мандатным разграничением доступа в Astra Linux Special Edition выбьет почву из-под ног. Файл, который вы сами создали пять минут назад, вдруг отказывается открываться с формулировкой «Permission denied» — при этом ls -l показывает, что вы владелец и права на чтение у вас есть. Это не баг и не повреждённая файловая система — это работает механизм, к которому дискреционная модель прав вас просто не готовила. Разберём, что происходит на самом деле и какие грабли на этом пути наступают чаще всего.

Чем мандатный подход принципиально отличается от дискреционного

Классическая модель прав в Unix — дискреционная (DAC, discretionary access control). Владелец объекта — файла, каталога — сам решает, кто и что с этим объектом может делать. Отсюда и название: право на доступ выдаётся «по усмотрению» (discretion) того, кто объектом владеет. Три группы прав — владелец, группа, остальные — три вида доступа — чтение, запись, выполнение. Всё локально: решение принимается на уровне конкретного файла конкретным человеком, и никакой внешней политики над этим нет. Именно поэтому chmod 777 — соблазнительно простой способ «починить» ошибку доступа: вы владелец, вы и разрешаете. Мы разбирали в отдельной статье, почему этот путь чаще ломает сервер, чем чинит — но в дискреционной модели он хотя бы логически работает.

Мандатный подход (MAC, mandatory access control) устроен по-другому. Решение о доступе принимает не владелец файла, а система — на основании политики, заданной администратором безопасности централизованно и обязательной для всех, включая владельца объекта. У каждого субъекта (пользователя, процесса) и каждого объекта (файла, каталога, сокета) есть метка — уровень конфиденциальности и, как правило, набор категорий. Доступ разрешается только тогда, когда соотношение меток субъекта и объекта удовлетворяет правилам политики. Иметь стандартные unix-права rwx на файл — необходимое, но недостаточное условие: мандатная проверка идёт поверх дискреционной, и первая же неудача перекрывает всё, что разрешила вторая.

Ключевое следствие: владелец файла в мандатной модели не всесилен. Он может создать файл, назначить ему права 644, отдать себе rwx — но если метка файла и метка его собственной сессии не совпадают нужным образом, ядро всё равно откажет. Это не исключение и не «странный случай» — это и есть суть мандатного контроля: политика задаётся не на уровне отдельного объекта, а на уровне всей системы, и переопределить её локальными правами нельзя.

Похожая логика — «решение принимает не приложение, а система на уровне ядра» — работает и в SELinux, только там метки называются контекстами безопасности, а не уровнями конфиденциальности. Если раньше приходилось разбираться с механикой SELinux, общий принцип — как SELinux принимает решение и почему отказ не виден в логах приложения — узнается почти один в один: мандатная проверка идёт вне поля зрения обычных инструментов диагностики прав.

Грабля №1: «я владелец, но файл не открывается»

Это первая и самая частая ловушка. Сценарий типовой: администратор заходит под своей учётной записью, создаёт файл, тут же пытается его открыть другим процессом или из-под другого сеанса того же пользователя (например, через cron, через sudo с иными атрибутами сессии, или после того, как файл скопировал другой процесс с иной меткой) — и получает отказ в доступе, хотя stat и ls -l показывают полный набор дискреционных прав.

Первый инстинкт — тот же, что при обычной unix-ошибке доступа: подкрутить права, сменить владельца, добавить в группу. На дискреционной модели это обычно помогает. На мандатной — нет, потому что причина отказа лежит не в правах, а в метках, а стандартные утилиты вроде ls -l эти метки чаще всего не показывают вообще — нужны отдельные, специфичные для мандатной подсистемы средства просмотра меток субъекта и объекта. Если смотреть только на классические unix-права, причина отказа физически не видна — отсюда и ощущение, что перед вами баг.

Second-order грабля отсюда: администратор, не разобравшись, начинает менять метку файла или снижать уровень конфиденциальности сессии, лишь бы «заработало» — по инерции повторяя логику chmod 777: не понять причину, а обойти симптом. В мандатной модели у такого обхода цена выше, чем у либеральных unix-прав: вы можете случайно понизить защищённость целой категории данных, а не одного файла.

Грабля №2: путаница между дискреционными правами и мандатным контролем при диагностике

Вторая типичная ошибка — диагностировать отказ доступа так же, как в обычном Linux: смотреть ls -l, проверять владельца, группу, ACL, если они настроены. Всё это по-прежнему актуально и может быть источником проблемы — мандатный механизм не отменяет дискреционный, а добавляется поверх него. Но если все дискреционные права выглядят корректными, а доступа всё равно нет, следующий шаг — проверять именно мандатную политику и метки, а не искать несуществующую ошибку в правах.

Практический вывод: у отказа в доступе на защищённой системе минимум два независимых уровня причин, и их нужно проверять по отдельности, а не вперемешку:

Отказ может произойти на любом из уровней независимо, и сообщение об ошибке на уровне приложения обычно не говорит, на каком именно — оно унифицировано до общего «отказано в доступе». Различать уровни приходится вручную, зная архитектуру, а не по тексту ошибки.

Грабля №3: копирование, перемещение и упаковка файлов между зонами конфиденциальности

Ещё одна ловушка возникает не в момент чтения, а в момент перемещения данных. Когда файл копируется, архивируется или передаётся между каталогами с разным уровнем конфиденциальности, встаёт вопрос: какую метку получит копия — метку источника, метку целевого каталога или метку текущей сессии процесса, который выполняет операцию? Ответ зависит от конкретной реализации и настроенной политики, и если администратор об этом не подумал заранее, результат бывает неожиданным в обе стороны: либо копия наследует более низкий уровень защищённости, чем оригинал (и это уже вопрос безопасности данных, а не удобства), либо, наоборот, получает более высокий уровень, чем нужно, и становится недоступна тем, кому по работе была нужна.

Резервное копирование — отдельная больная тема: универсальные бэкап-инструменты, которые не умеют работать с мандатными метками, могут либо потерять их при архивации (и тогда восстановленные файлы окажутся с дефолтной, часто самой низкой меткой), либо вовсе споткнуться о попытку прочитать объект с более высоким уровнем конфиденциальности, чем у процесса резервного копирования. Это нужно проверять на тестовом стенде до того, как система уйдёт в продуктив, а не выяснять на первом реальном инциденте.

Почему нельзя начинать работу без понимания модели меток

Соблазн пропустить теорию и сразу «настроить как-нибудь» на мандатной системе обходится дороже, чем на обычном Linux — по трём причинам.

Во-первых, ошибки конфигурирования мандатной политики не всегда проявляются сразу и явно. Слишком широкая политика — это не отказ в доступе, который сразу заметен и который сразу чинят, а тихо расширенные права, которые обнаруживаются только на аудите или, хуже, после инцидента.

Во-вторых, объяснение «поставьте setenforce 0-аналог и живите спокойно» — соблазн, который прямо противоречит смыслу внедрения такой системы. Если система выбрана или предписана именно ради мандатного контроля (а для Astra Linux Special Edition это часто требование регулятора, а не личный выбор администратора), отключение мандатного механизма означает, что формальное требование выполнено (дистрибутив стоит), а фактическая защита — нет. Это тот же антипаттерн, что и отключить SELinux и забыть — только цена ошибки выше, потому что мандатный контроль в защищённых дистрибутивах обычно завязан на требования по защите информации, а не просто на удобство администрирования.

В-третьих, модель меток нужно спроектировать до того, как система начнёт использоваться — так же, как схему прав доступа проектируют до продакшена, а не чинят по факту жалоб пользователей. Добавить категории и уровни задним числом, когда на файловой системе уже тысячи объектов с невнятной или дефолтной разметкой, кратно дороже, чем продумать схему заранее: кто с какими данными работает, какие уровни конфиденциальности реально нужны (не абстрактно «побольше», а исходя из реальных категорий данных), какие сервисы и процессы должны иметь доступ к каким меткам.

Практический минимум перед стартом: прежде чем создавать первого пользователя и первый защищённый каталог, нужно чётко ответить на четыре вопроса — сколько уровней конфиденциальности реально нужно организации, какие категории данных существуют и не пересекаются ли они по смыслу, какие сервисные учётные записи (веб-сервер, СУБД, бэкап-агент) должны читать и писать в каких зонах, и что произойдёт с существующими данными при первом включении политики — они получат метку по умолчанию, и эта метка может быть не той, которую вы ожидаете.

Как переносить существующую инфраструктуру и не сломать привычные процессы

Если Astra Linux разворачивается не с нуля, а как замена уже работающей Ubuntu- или Debian-инфраструктуры, к граблям с метками добавляются грабли миграции: скрипты, которые раньше молча писали куда угодно правами процесса, начинают спотыкаться о мандатные проверки, о которых их авторы не подозревали. Мандатное разграничение доступа — как раз один из источников сюрпризов, которые не видны на этапе «установили, всё запустилось», а всплывают только тогда, когда система начинает обрабатывать реальные данные с реальными метками.

Практический совет здесь простой, но его часто игнорируют: не переносите продакшен-нагрузку на мандатную систему до того, как прогоните на тестовом контуре полный цикл операций — создание файлов сервисными учётками, резервное копирование, ротацию логов, обновление приложений, взаимодействие с внешними хранилищами. Каждая из этих операций может упереться в мандатную проверку в неожиданном месте, и находить это нужно на стенде, а не в момент, когда систему уже сдали заказчику или регулятору.

Где брать актуальную документацию по конкретной версии

Мандатное разграничение доступа — стандартная концепция информационной безопасности, но её конкретная реализация (названия команд, формат меток, набор доступных уровней и категорий, интерфейсы управления политикой) — это деталь конкретного дистрибутива и конкретной версии. Здесь стоит держать в голове три вещи.

Первое: официальная документация разработчика дистрибутива — единственный источник, которому можно доверять по названиям конкретных утилит и параметров. Общие статьи в интернете (включая эту) правильно объясняют принцип, но могут расходиться с актуальной версией по деталям синтаксиса — версии дистрибутива меняются, интерфейсы управления мандатной политикой между релизами тоже могут меняться.

Второе: у защищённых дистрибутивов обычно есть отдельная документация по настройке под конкретные требования регуляторов (какие уровни и категории использовать для каких классов информации) — это не техническая, а методическая часть, и её тоже нужно смотреть в актуальной редакции, а не по памяти или по статьям трёхлетней давности.

Третье: если систему предстоит аттестовать или сертифицировать, схема мандатных меток должна согласовываться не только с технической документацией дистрибутива, но и с внутренними регламентами организации и требованиями регулятора — сама по себе техническая настройка мандатного контроля не гарантирует соответствия, это вопрос более широкий, чем конфигурация одного сервера.

Отдельно стоит закладывать время на проверку прикладного ПО в условиях мандатной модели и замкнутой программной среды — если в организации уже включён контроль запуска только разрешённых программ, к граблям с метками файлов добавляются грабли с разрешением на исполнение. Оба механизма стоит включать по отдельности и тестировать по отдельности, а не разом на боевой системе — иначе при отказе в доступе будет сложно понять, какой именно из двух контуров защиты сработал.

Частые вопросы