Política MAC del motor de seguridad SELinux de Linux

Junto con el control de acceso obligatorio implementado con SELinux LSM, SELinux LSM MAC es una política de seguridad del sistema que difiere de la política del propietario en el DAC, que determina a quién se le debe permitir el acceso a qué información.
La política MAC proporcionada por SELinux se basa en dos tipos de política:

Type Enforcement (TE), que se utiliza para implementar un modelo de control de acceso basado en roles
Seguridad multinivel (MLS) con una política de etiquetado jerárquica Bell-LaPadula.

Los sujetos y objetos en Linux son procesos y subprocesos normales del kernel. Ambos están representados por una estructura task_struct. Los subprocesos del kernel se ejecutan solo en modo privilegiado y no están limitados por la política de MAC. Todos los objetos con nombre, como archivos normales, archivos de texto y de bloque, directorios, sockets y objetos IPC, están controlados por la política MAC. La política MAC puede controlar no solo los objetos con nombre, sino también el acceso a estructuras de datos del kernel específicas, como descriptores de archivos, mensajes IPC y sistemas de archivos, para permitir una definición más granular de políticas de seguridad del sistema.

Los atributos de seguridad de sujeto y objeto, también llamados contextos de seguridad de SELinux, tienen el mismo formato. En un formato externo fácil de usar, el contexto de seguridad es una secuencia de caracteres ASCII. Por motivos de rendimiento, el kernel convierte esta secuencia en un entero de 32 bits en tiempo de ejecución; sin embargo, al describir el mecanismo de aplicación y la política de seguridad, el contexto de seguridad se presenta en formato ASCII. Un contexto de seguridad tiene cuatro componentes separados por dos puntos. Corresponden al usuario, rol, tipo y rango MLS del sujeto u objeto /

Usuario: componente de usuario – nombre de usuario de SELinux.
Rol: El componente de rol es un rol de SELinux que corresponde a un sujeto u objeto. Para los sujetos, un rol se usa para hacer cumplir un modelo de control de acceso basado en roles, lo que permite que el rol controle el acceso a los dominios. Para los objetos, el componente de rol no se usa y lo es todo object_r.
Tipo: el campo de tipo representa el tipo de objeto o el dominio del tema. Los dominios y los tipos son clases equivalentes para procesos y recursos, respectivamente. El acceso al kernel se otorga según el tipo de objeto y el dominio del sujeto.
Rango de marcadores MLS: el rango de marcadores MLS contiene dos marcadores MLS completos. Se colocan de modo que el marcador inferior esté a la izquierda y el marcador superior, que predomina sobre el marcador inferior, esté a la derecha. Los dos marcadores están separados por un guión en forma de em y forman el rango de marcadores. Para los sujetos, el marcador de rango inferior corresponde al marcador MLS válido del sujeto, mientras que el marcador superior corresponde a los permisos de acceso del sujeto. El nivel de acceso de un sujeto corresponde a la autoridad del usuario en cuyo nombre actúa el sujeto.

Para objetos como archivos normales, la política de seguridad dicta que el marcador inferior y el marcador superior son iguales; así, el objeto tiene, de hecho, un solo nivel. Otros objetos, como directorios, dispositivos y sockets, pueden tener un marcador superior que no sea igual al marcador inferior. Estos objetos están en capas y su rango de marcador MLS requiere que el nivel de seguridad de cualquier información que pase a través de ellos determine el valor del marcador inferior y, al mismo tiempo, esté determinado por el marcador superior.
Cada marcador MLS tiene dos componentes: un nivel de clasificación jerárquico (o nivel de seguridad) y un conjunto de categorías no jerárquicas.
Hay cuatro posibles relaciones entre dos tokens MLS cualesquiera, definidos de la siguiente manera (en la siguiente lista, L1 es el marcador inferior del sujeto que realiza la solicitud de acceso y L2 es el marcador inferior del acceso solicitado al objeto):

L1 es igual a L2 (los niveles son iguales, los conjuntos de categorías son iguales),
L1 anula L2 (Capa L1> = Capa L2, el conjunto de categorías L2 es el mismo o es un subconjunto del conjunto de categorías L1),
L1 es anulado por L2 (L2> = L1, el conjunto de categorías L1 es el mismo o un subconjunto del conjunto de categorías L2),
L1 es incomparable a L2 (L1 y L2 no son iguales y ninguno anula al otro).

Almacenamiento de atributos Los atributos de SELinux se almacenan:

en la estructura del proceso task_struct para los sujetos;
en la estructura de datos ubicada en el disco y en el kernel, para los objetos en el sistema de archivos;
en la estructura de datos kern_ipc_perm de los objetos IPC del Sistema V;
en la estructura de datos sock para sockets;
en la estructura xfrm_state para enchufes netlink;
en la estructura de datos key de las claves.

SELinux lanza contextos inválidos o inválidos al contexto system_u:object_r:unlabeled_t:s0.
Reglas de control de acceso La implementación del control de acceso MAC se basa en Type Enforcement (TE). TE proporciona un control más granular sobre el acceso a sujetos y objetos.
Las reglas de política de TE y MLS se definen con la política de SELinux. Las reglas de TE se definen como comprobaciones de control de acceso, mientras que la política MLS se define como una restricción impuesta sobre TE. Por lo tanto, se realiza una verificación completa del control de acceso en tres pasos lógicos, como sigue:

La validación de DAC se realiza primero, utilizando los atributos de DAC, seguido de
TE verifica usando dominios y tipos de contexto de seguridad de SELinux seguidos de
Verificación de la política MLS de Bell-LaPadula utilizando el rango de tokens MLS del contexto de seguridad de SELinux.

Cada uno de los controles realizados no está autorizado. Por lo tanto, los derechos de acceso solo son más limitados en cada etapa posterior; una denegación de acceso establecida por una política de DAC no puede ser anulada por un TE, y una denegación de acceso establecida por un TE no puede ser anulada por MLS.
Los privilegios relacionados con el software para la política MAC se implementan utilizando el dominio de protección de procesos y las reglas de la política de seguridad asociadas con ese dominio. Por ejemplo, procesos que se ejecutan en el dominio init_t, concedió acceso de lectura a objetos cuyo token de contexto de seguridad prevalece sobre el token de contexto de seguridad del proceso. Esta anulación está determinada por los atributos del dominio. La regla de política establece el acceso al dominio en un tipo anulado vinculado a un atributo de dominio. Por ejemplo, la siguiente regla de política se puede utilizar para permitir que un proceso anule la restricción Bell-LaPadula que niega el acceso de lectura cuando ese proceso intenta leer un archivo normal:

Listado 3.1: Restricción de la política MLS de SELinux
mlsconstrain { file } { read } (( l1 dom l2) or (t1 == mlsfileread ))
La declaración anterior establece una política de seguridad según la cual el token l1 (propiedad del sujeto) debe prevalecer sobre el token l2 (propiedad del objeto) para que una operación de lectura de datos permita el acceso de lectura si el dominio del proceso no tiene ningún atributo mlsfileread.
La política de seguridad del sistema para varios tipos de sujetos y objetos se da en las descripciones funcionales de estos sujetos y objetos.
Además tiene las siguientes características a los atributos del proceso que puede anular los derechos de acceso, el núcleo de Linux: CAP_MAC_OVERRIDE. Si un proceso tiene esta capacidad, puede omitir la aplicación de todas las políticas de SELinux.