Принудительное применение типа

Принудительное применение типа допускает детализированное управление операционной системой, позволяя не только контролировать выполнение процессов, но также и переходы между доменами или схемы авторизации. По этой причине механизм чаще всего реализуется в виде модуля ядра, как это реализовано в SELinux. Использование принудительного применения типа является способом реализации архитектуры FLASK.

С использованием принудительного применения типа пользователи могут (как в Microsoft Active Directory) или не могут (как в SELinux) быть ассоциированы с областью англ. Kerberos, хотя исходная модель TE предполагает такую ассоциацию. Необходимо обязательно определять TE-матрицу доступа, содержащую правила о правах доступа для заданного контекста безопасности, либо права субъекта на объекты в соответствии с определённой схемой авторизации.

На практике принудительное применение типа предполагает оценку набора правил исходного контекста безопасности субъекта по отношению к набору правил целевого контекста безопасности объекта. Решение о разрешении доступа принимается на основании TE-описания доступа (матрицы). После этого применяются DAC и другие механизмы контроля доступа (MLS / MCS и др.).

Концепция принудительного применения типа была впервые представлена в архитектуре Secure Ada Target в конце 1980-х годов, а её полная реализация была осуществлена в логическом сопроцессорном ядре (англ. Logical Coprocessing Kernel, система LOCK). Межсетевой экран Sidewinder был реализован на специальной версии Unix, включающей принудительное применение типа.

Вариант, известный как принудительное применение типа домена (англ. domain type enforcement), был разработан в системе Trusted MACH.

Изначально модель принудительного применения типа предполагала, что метки должны быть прикреплены и к субъектам, и к объектам: «метка домена» для субъекта и «метка типа» для объекта. Механизм реализации был усовершенствован архитектурой FLASK, которая заменила сложные структуры и неявные отношения. Также оригинальная TE-матрица доступа была расширена на другие структуры: построенные на решётках, базирующиеся на истории, зависящие от окружения, реализующие определённую логику политики и др. Особенности реализации TE зависят от конкретной операционной системы. В SELinux реализация не различает TE-домены и TE-типы на внутреннем уровне. Считается недостатком исходной модели TE слишком детальное описание аспектов реализации, таких как метки и матрицы, особенно с использованием терминов «домен» и «тип», которые имеют иные, более общие и широко употребимые значения.

В современных операционных системах семейства Windows (Windows 11 и Windows Server 2025) механизмы контроля приложений реализуют концепции, близкие к принудительному применению типа. Основными инструментами выступают Windows Defender Application Control (WDAC) и AppLocker^[1][2]. WDAC работает на уровне ядра и использует XML-политики для строгого контроля выполнения кода. AppLocker функционирует на уровне пользователя и в настоящее время считается устаревшим.

В операционной системе Solaris компонент Solaris Trusted Extensions использует политику безопасности, основанную на механизме привилегий процессов, а мандатный доступ реализуется через виртуальные контейнеры (зоны).

Для FreeBSD существовал экспериментальный порт SEBSD, реализованный в виде подключаемого модуля через фреймворк TrustedBSD MAC, однако в настоящее время этот проект является устаревшим^[3][4].

В архитектуре современных агентов на базе больших языковых моделей (LLM) механизм принудительного исполнения применяется для создания границы между вероятностным поведением модели и детерминированным контролем. Для реализации этого механизма используются системные перехватчики (например, хуки в Claude Code), которые встраиваются в конвейер принятия решений. Они контролируют вызовы инструментов, перехватывая их до фактического выполнения, и гарантируют соблюдение политик безопасности независимо от рассуждений нейросети^[5].^[6]