Принудительное управление типами в информационных системах.
Type enforcement
Принудительное управление типами (TE) в IT: механизм контроля доступа, приоритет MAC над DAC. Безопасность через контекст и политику домена в Linux/SELinux.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Концепция принудительного контроля типов (TE) в области информационных технологий — это механизм контроля доступа, предназначенный для регулирования доступа в компьютерных системах. Реализация TE придает приоритет обязательному контролю доступа (MAC) над дискреционным контролем доступа (DAC). Право доступа предоставляется субъекту (например, процессу), обращающемуся к объектам (например, файлам, записям, сообщениям) на основе правил, определенных в присоединенном контексте безопасности. Контекст безопасности в домене определяется политикой безопасности домена. В модуле безопасности Linux (LSM) в SELinux контекст безопасности является расширенным атрибутом. Реализация принудительного контроля типов является предварительным условием для MAC и первым шагом к многоуровневой безопасности (MLS) или ее замене – многокатегорийной безопасности (MCS). Она дополняет контроль доступа на основе ролей (RBAC).
The concept of type enforcement (TE), in the field of information technology, is an access control mechanism for regulating access in computer systems. Implementing TE gives priority to mandatory access control (MAC) over discretionary access control (DAC). Access clearance is first given to a subject (e. g. process) accessing objects (e. g. files, records, messages) based on rules defined in an attached security context. A security context in a domain is defined by a domain security policy. In the Linux security module (LSM) in SELinux, the security context is an extended attribute. Type enforcement implementation is a prerequisite for MAC, and a first step before multilevel security (MLS) or its replacement multi categories security (MCS). It is a complement of role based access control (RBAC).
Контроль
Применение принудительной типизации подразумевает тонкий контроль над операционной системой, не только для управления выполнением процессов, но и для управления переходом между доменами или схемой авторизации. Именно поэтому оно лучше всего реализуется как модуль ядра, как это сделано в SELinux. Использование принудительной типизации – это один из способов реализации архитектуры FLASK.
Type enforcement implies fine grained control over the operating system, not only to have control over process execution, but also over domain transition or authorization scheme. This is why it is best implemented as a kernel module, as is the case with SELinux. Using type enforcement is a way to implement the FLASK architecture.
Доступ
Используя принудительное исполнение типов, пользователи могут быть связаны с областью Kerberos (как в Microsoft Active Directory) или не быть связаны с ней (как в SELinux), хотя изначальная модель принудительного исполнения типов подразумевает такую связь. Всегда необходимо определить матрицу доступа TE, содержащую правила о правах доступа, предоставленных в заданном контексте безопасности, или о правах субъекта на объекты в соответствии со схемой авторизации.
Using type enforcement, users may (as in Microsoft Active Directory) or may not (as in SELinux) be associated with a Kerberos realm, although the original type enforcement model implies so. It is always necessary to define a TE access matrix containing rules about clearance granted to a given security context, or subject's rights over objects according to an authorization scheme.
Безопасность
На практике, принудительный контроль типов оценивает набор правил из контекста безопасности субъекта по отношению к набору правил из контекста безопасности объекта. Решение о допуске принимается в зависимости от описания доступа TE (матрицы). Затем применяются DAC или другие механизмы контроля доступа (MLS / MCS).
Practically, type enforcement evaluates a set of rules from the source security context of a subject, against a set of rules from the target security context of the object. A clearance decision occurs depending on the TE access description (matrix). Then, DAC or other access control mechanisms (MLS / MCS, ) apply.
История
В конце 1980-х годов принудительное использование типов было внедрено в архитектуру Secure Ada Target с полной реализацией, разработанной в системе LOCK (Logical Coprocessing Kernel). Брандмауэр Sidewinder Internet Firewall был реализован на специализированной версии Unix, включающей принудительное использование типов. В системе Trusted MACH был разработан вариант, известный как обеспечение соблюдения типов доменов. Изначальная модель принудительного использования типов определяла, что метки должны быть привязаны к субъекту и объекту: метка домена для субъекта и метка типа для объекта. Этот механизм реализации был усовершенствован архитектурой FLASK, заменившей сложные структуры и неявные связи. Кроме того, исходная матрица доступа TE была расширена до других структур: основанных на решетке, истории, окружении и логике политик. Это вопрос реализации TE различными операционными системами. В SELinux реализация TE не различает внутренне домен TE и типы TE. Следует рассматривать как слабость исходной модели TE указание детальных аспектов реализации, таких как метки и матрица, особенно с использованием терминов "домен" и "типы", которые имеют другие, более общие и широко принятые значения.
Type enforcement was introduced in the Secure Ada Target architecture in the late 1980s with a full implementation developed in the Logical Coprocessing Kernel (LOCK) system. The Sidewinder Internet Firewall was implemented on a custom version of Unix that incorporated type enforcement. A variant called domain type enforcement was developed in the Trusted MACH system. The original type enforcement model stated that labels should be attached to subject and object: a “domain label” for a subject and a “type label” for an object. This implementation mechanism was improved by the FLASK architecture, substituting complex structures and implicit relationship. Also, the original TE access matrix was extended to other structures: lattice based, history based, environment based, policy logic This is a matter of implementation of TE by the various operating systems. In SELinux, TE implementation does not internally distinguish TE domain from TE types. It should be considered a weakness of TE original model to specify detailed implementation aspects such as labels and matrix, especially using the terms “domain” and “types” which have other, more generic, widely accepted meanings.