En seguridad informática , el control de acceso obligatorio ( MAC ) se refiere a un tipo de control de acceso por el cual un entorno seguro (por ejemplo, un sistema operativo o una base de datos) restringe la capacidad de un sujeto o iniciador de acceder o modificar un objeto o destino . [1] En el caso de los sistemas operativos, el sujeto es un proceso o hilo, mientras que los objetos son archivos, directorios, puertos TCP / UDP , segmentos de memoria compartida o dispositivos IO. Los sujetos y los objetos tienen cada uno un conjunto de atributos de seguridad. Siempre que un sujeto intenta acceder a un objeto, el núcleo del sistema operativo examina estos atributos de seguridad, examina las reglas de autorización (también conocidas como política ) vigentes y decide si conceder acceso. Un sistema de gestión de bases de datos , en su mecanismo de control de acceso, también puede aplicar el control de acceso obligatorio; en este caso, los objetos son tablas, vistas, procedimientos, etc.
En el control de acceso obligatorio, la política de seguridad está controlada de forma central por un administrador de políticas y se garantiza (en principio) su aplicación para todos los usuarios. Los usuarios no pueden anular la política y, por ejemplo, conceder acceso a archivos que de otro modo estarían restringidos. Por el contrario, el control de acceso discrecional (DAC), que también regula la capacidad de los sujetos para acceder a los objetos, permite a los usuarios tomar decisiones sobre políticas o asignar atributos de seguridad.
Histórica y tradicionalmente, MAC ha estado estrechamente asociada con la seguridad multinivel (MLS) y los sistemas militares especializados. En este contexto, MAC implica un alto grado de rigor para satisfacer las limitaciones de los sistemas MLS. Sin embargo, más recientemente, [ ¿cuándo? ] , MAC se ha desviado del nicho de MLS y ha comenzado a volverse más común. Las implementaciones de MAC más recientes, como SELinux y AppArmor para Linux y Mandatory Integrity Control para Windows, permiten a los administradores centrarse en problemas como ataques a la red y malware sin el rigor o las limitaciones de MLS.
Históricamente, MAC se asoció fuertemente con la seguridad multinivel (MLS) como un medio para proteger la información clasificada de los Estados Unidos . Los Criterios de evaluación de sistemas informáticos de confianza (TCSEC), el trabajo seminal sobre el tema y a menudo conocido como el Libro Naranja, proporcionaron la definición original de MAC como "un medio para restringir el acceso a objetos en función de la sensibilidad (representada por una etiqueta) de la información contenida en los objetos y la autorización formal (es decir, autorización) de los sujetos para acceder a información de dicha sensibilidad". [2] Las primeras implementaciones de MAC como SCOMP de Honeywell , SACDIN de la USAF , Blacker de la NSA y MLS LAN de Boeing se centraron en MLS para proteger los niveles de clasificación de seguridad orientados a lo militar con una aplicación sólida.
La palabra "obligatorio" en MAC ha adquirido un significado especial derivado de su uso en sistemas militares. En este contexto, MAC implica un grado extremadamente alto de robustez que asegura que los mecanismos de control puedan resistir cualquier tipo de subversión, lo que les permite hacer cumplir los controles de acceso que son obligatorios por orden de un gobierno, como la Orden Ejecutiva 12958. Se supone que la aplicación es más imperativa que para las aplicaciones comerciales. Esto excluye la aplicación mediante mecanismos de máximo esfuerzo. Solo los mecanismos que pueden proporcionar una aplicación absoluta o casi absoluta del mandato son aceptables para MAC. Esto es una tarea difícil y a veces se considera poco realista para quienes no están familiarizados con las estrategias de alta seguridad, y muy difícil para quienes sí lo están.
En algunos sistemas, los usuarios tienen la autoridad de decidir si conceden o no acceso a cualquier otro usuario. Para permitirlo, todos los usuarios tienen autorizaciones para todos los datos. Esto no es necesariamente cierto en el caso de un sistema MLS. Si existen personas o procesos a los que se les puede negar el acceso a cualquiera de los datos del entorno del sistema, entonces se debe confiar en que el sistema hará cumplir la MAC. Dado que puede haber varios niveles de clasificación de datos y autorizaciones de usuario, esto implica una escala cuantificada de robustez. Por ejemplo, se indica una mayor robustez para entornos de sistema que contienen información clasificada "Top Secret" y usuarios no autorizados que para uno con información "Secreta" y usuarios autorizados al menos a "Confidencial". Para promover la coherencia y eliminar la subjetividad en los grados de robustez, un análisis científico extenso y una evaluación de riesgos del tema produjeron una estandarización de referencia histórica que cuantifica las capacidades de robustez de seguridad de los sistemas y las asigna a los grados de confianza justificados para varios entornos de seguridad. El resultado se documentó en CSC-STD-004-85. [3] Se definieron dos componentes relativamente independientes de la robustez: nivel de garantía y funcionalidad . Ambos fueron especificados con un grado de precisión que justificaba una confianza significativa en las certificaciones basadas en estos criterios.
El estándar Common Criteria [4] se basa en esta ciencia y pretendía preservar el nivel de garantía como niveles EAL y las especificaciones de funcionalidad como perfiles de protección . De estos dos componentes esenciales de los puntos de referencia de robustez objetivos, solo los niveles EAL se conservaron fielmente. En un caso, el nivel C2 de TCSEC [5] (no una categoría con capacidad MAC) se conservó bastante fielmente en Common Criteria, como el Perfil de protección de acceso controlado (CAPP). [6] Los perfiles de protección MLS (como MLSOSPP similar a B2) [7] son más generales que B2. Son conformes a MLS, pero carecen de los requisitos de implementación detallados de sus predecesores del Libro Naranja , centrándose más en los objetivos. Esto da a los certificadores una mayor flexibilidad subjetiva para decidir si las características técnicas del producto evaluado logran adecuadamente el objetivo, lo que potencialmente erosiona la consistencia de los productos evaluados y facilita la obtención de la certificación para productos menos confiables. Por estas razones, la importancia de los detalles técnicos del perfil de protección es fundamental para determinar la idoneidad de un producto.
Este tipo de arquitectura impide que un usuario o proceso autenticado en una clasificación o nivel de confianza específicos acceda a información, procesos o dispositivos de un nivel diferente. Esto proporciona un mecanismo de contención de usuarios y procesos, tanto conocidos como desconocidos. Un programa desconocido puede incluir una aplicación no confiable en la que el sistema debería supervisar o controlar los accesos a dispositivos y archivos.
A finales del milenio pasado, algunas implementaciones MAC, como el proyecto Blacker de Unisys , obtuvieron la certificación de robustez suficiente para separar el alto secreto del no clasificado. La tecnología subyacente se volvió obsoleta y no se actualizaron. Hoy en día, no existen implementaciones actuales certificadas por TCSEC con ese nivel de robustez. Sin embargo, existen algunos productos menos robustos.
A partir de Windows Vista y Server 2008 , Microsoft ha incorporado el Control de integridad obligatorio (MIC) en el sistema operativo Windows, que agrega niveles de integridad (IL) a los procesos en ejecución. El objetivo es restringir el acceso de los procesos menos confiables a la información confidencial. MIC define cinco niveles de integridad: Bajo, medio, alto, sistema e instalador confiable. [8] De manera predeterminada, los procesos se inician en IL medio. Los procesos elevados reciben IL alto. [9] Los procesos secundarios, de manera predeterminada, heredan la integridad de su padre, aunque el proceso padre puede iniciarlos con un IL menor. Por ejemplo, Internet Explorer 7 inicia sus subprocesos con IL bajo. Windows controla el acceso a los objetos según los IL. Los objetos con nombre , incluidos los archivos , las claves de registro u otros procesos y subprocesos , tienen una entrada en su ACL que indica el IL mínimo del proceso que puede usar el objeto. MIC exige que un proceso pueda escribir o eliminar un objeto solo cuando su IL sea igual o mayor que el IL del objeto. Además, para evitar el acceso a datos confidenciales en la memoria, los procesos no pueden abrir procesos con un IL más alto para acceso de lectura . [10]
Apple Inc. ha incorporado una implementación del marco TrustedBSD en sus sistemas operativos iOS y macOS . [11] (La palabra "mac" en "macOS" es la abreviatura de " Macintosh " y no tiene nada que ver con la abreviatura de "control de acceso obligatorio"). La función de línea de comandos sandbox_initproporciona una interfaz de sandbox de alto nivel limitada. [12]
La versión 5.0 y posteriores del sistema operativo Android , desarrollado por Google , utilizan SELinux para aplicar un modelo de seguridad MAC además de su enfoque DAC original basado en UID. [13]
Linux y muchas otras distribuciones Unix tienen direcciones MAC para CPU (multianillo), disco y memoria. Si bien el software del sistema operativo puede no administrar bien los privilegios, Linux se hizo famoso durante la década de 1990 por ser más seguro y mucho más estable que las alternativas que no eran Unix. [ cita requerida ]
El RSBAC (Control de acceso basado en conjuntos de reglas) de Amon Ott proporciona un marco para los núcleos de Linux que permite varios módulos de decisión/política de seguridad diferentes. Uno de los modelos implementados es el modelo de control de acceso obligatorio. Un objetivo general del diseño de RSBAC era intentar alcanzar el nivel B1 (obsoleto) del Libro Naranja (TCSEC). El modelo de control de acceso obligatorio utilizado en RSBAC es en gran parte el mismo que en Unix System V/MLS, versión 1.2.1 (desarrollado en 1989 por el Centro Nacional de Seguridad Informática de los EE. UU. con clasificación B1/TCSEC). RSBAC requiere un conjunto de parches para el núcleo original, que son mantenidos bastante bien por el propietario del proyecto .
Smack (Simplified Mandatory Access Control Kernel) es un módulo de seguridad del kernel de Linux que protege la interacción entre datos y procesos de manipulaciones maliciosas mediante un conjunto de reglas de control de acceso obligatorio personalizadas, con la simplicidad como su principal objetivo de diseño. [14] Se ha fusionado oficialmente desde el lanzamiento de Linux 2.6.25. [15]
TOMOYO Linux es una implementación MAC ligera para Linux y Embedded Linux , desarrollada por NTT Data Corporation . Se ha fusionado en la versión principal de Linux Kernel 2.6.30 en junio de 2009. [16] A diferencia del enfoque basado en etiquetas utilizado por SELinux , TOMOYO Linux realiza un Control de Acceso Obligatorio basado en nombres de ruta , separando los dominios de seguridad según el historial de invocación de procesos, que describe el comportamiento del sistema. Las políticas se describen en términos de nombres de ruta. Un dominio de seguridad se define simplemente por una cadena de llamadas de proceso y se representa mediante una cadena. Hay 4 modos: deshabilitado, aprendiendo , permisivo, imponiendo. Los administradores pueden asignar diferentes modos para diferentes dominios. TOMOYO Linux introdujo el modo de "aprendizaje", en el que los accesos ocurridos en el núcleo se analizan y almacenan automáticamente para generar una política MAC: este modo podría ser el primer paso de la redacción de políticas, lo que facilita su personalización posterior.
SUSE Linux y Ubuntu 7.10 han añadido una implementación MAC llamada AppArmor , que utiliza la interfaz de módulos de seguridad de Linux (LSM) de Linux 2.6. LSM proporciona una API de kernel que permite que los módulos de código de kernel controlen las ACL (DAC ACL, listas de control de acceso). AppArmor no es capaz de restringir todos los programas y está opcionalmente en el kernel de Linux a partir de la versión 2.6.36. [17]
grsecurityes un parche para el kernel de Linux que proporciona una implementación MAC (precisamente, es una implementación RBAC ). grsecurityno se implementa a través de la API LSM . [18]
El sistema operativo Astra Linux desarrollado para el ejército ruso tiene su propio control de acceso obligatorio. [19]
FreeBSD es compatible con el control de acceso obligatorio , implementado como parte del proyecto TrustedBSD. Se introdujo en FreeBSD 5.0. A partir de FreeBSD 7.2, la compatibilidad con MAC está habilitada de forma predeterminada. El marco es extensible; varios módulos MAC implementan políticas como Biba y seguridad multinivel .
Sun's Trusted Solaris utiliza un mecanismo de control de acceso (MAC) obligatorio e impuesto por el sistema, en el que se utilizan autorizaciones y etiquetas para aplicar una política de seguridad. Sin embargo, tenga en cuenta que la capacidad de gestionar etiquetas no implica la fortaleza del núcleo para operar en modo de seguridad multinivel [ cita requerida ] . El acceso a las etiquetas y los mecanismos de control no están [ cita requerida ] protegidos de forma robusta contra la corrupción en un dominio protegido mantenido por un núcleo. Las aplicaciones que ejecuta un usuario se combinan con la etiqueta de seguridad en la que trabaja el usuario en la sesión. El acceso a la información, los programas y los dispositivos solo están controlados de forma débil [ cita requerida ] .