En seguridad informática , el control de acceso obligatorio ( MAC ) se refiere a un tipo de control de acceso mediante el cual un entorno seguro (por ejemplo, un sistema operativo o una base de datos) restringe la capacidad de un sujeto o iniciador para acceder o modificar un objeto u objetivo . [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 objetos tienen cada uno un conjunto de atributos de seguridad. Cada vez 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íticas ) vigentes y decide si otorga acceso. Un sistema de gestión de bases de datos , en su mecanismo de control de acceso, también puede aplicar 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 centralmente 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, otorgar acceso a archivos que de otro modo estarían restringidos. Por el contrario, el control de acceso discrecional (DAC), que también rige la capacidad de los sujetos para acceder a objetos, permite a los usuarios tomar decisiones políticas o asignar atributos de seguridad.
Histórica y tradicionalmente, MAC ha estado estrechamente asociado 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. Más recientemente, [ ¿ cuándo? ] sin embargo, MAC se ha desviado del nicho de la MLS y ha comenzado a volverse más común. Las implementaciones MAC más recientes, como SELinux y AppArmor para Linux y Mandatory Integrity Control para Windows, permiten a los administradores centrarse en cuestiones como ataques de red y malware sin el rigor ni las limitaciones de MLS.
Históricamente, MAC estuvo fuertemente asociado con la seguridad multinivel (MLS) como medio para proteger información clasificada de Estados Unidos . Los Criterios de evaluación de sistemas informáticos confiables (TCSEC), el trabajo fundamental 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 tal 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 al ejército con una aplicación estricta.
La palabra "obligatorio" en MAC ha adquirido un significado especial derivado de su uso con 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, permitiéndoles así hacer cumplir los controles de acceso ordenados por orden de un gobierno como la Orden Ejecutiva 12958 . Se supone que la aplicación de la ley es más imperativa que en el caso de las aplicaciones comerciales. Esto impide la aplicación mediante mecanismos de máximo esfuerzo. Para MAC sólo son aceptables los mecanismos que puedan proporcionar una aplicación absoluta o casi absoluta del mandato. Se trata de una tarea difícil y, a veces, considerada poco realista por 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 otorgan acceso a cualquier otro usuario. Para permitir eso, 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 en el entorno del sistema, entonces se debe confiar en que el sistema aplicará MAC. Dado que puede haber varios niveles de clasificación de datos y autorizaciones de usuarios, esto implica una escala cuantificada de robustez. Por ejemplo, se indica una mayor solidez para entornos de sistema que contienen información clasificada "Alto Secreto" 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 solidez, un análisis científico exhaustivo y una evaluación de riesgos del tema produjeron una estandarización de referencia histórica que cuantifica las capacidades de solidez de la seguridad de los sistemas y las asigna a los grados de confianza garantizados para diversos entornos de seguridad. El resultado se documentó en CSC-STD-004-85. [3] Se definieron dos componentes de robustez relativamente independientes: nivel de garantía y funcionalidad . Ambos se especificaron con un grado de precisión que garantizaba una confianza significativa en las certificaciones basadas en estos criterios.
El estándar Common Criteria [4] se basa en esta ciencia y pretende preservar el nivel de seguridad como niveles EAL y las especificaciones de funcionalidad como perfiles de protección . De estos dos componentes esenciales de los puntos de referencia objetivos de robustez, sólo los niveles EAL se preservaron fielmente. En un caso, el nivel TCSEC C2 [5] (no es una categoría compatible con MAC) se conservó bastante fielmente en los Criterios Comunes, como 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. Se ajustan al MLS, pero carecen de los requisitos de implementación detallados de sus predecesores del Libro Naranja , centrándose más en los objetivos. Esto les da a los certificadores más 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 estos motivos, la importancia de los detalles técnicos del Perfil de Protección es fundamental para determinar la idoneidad de un producto.
Dicha arquitectura evita que un usuario o proceso autenticado en una clasificación o nivel de confianza específico acceda a información, procesos o dispositivos en un nivel diferente. Esto proporciona un mecanismo de contención de usuarios y procesos, tanto conocidos como desconocidos. Un programa desconocido puede comprender una aplicación que no es de confianza donde el sistema debería monitorear o controlar el acceso a dispositivos y archivos.
Algunas implementaciones MAC, como el proyecto Blacker de Unisys , fueron certificadas lo suficientemente robustas como para separar Top Secret de Unclassified a finales del último milenio. Su tecnología subyacente quedó obsoleta y no fueron actualizadas. Hoy en día no hay implementaciones certificadas por TCSEC a ese nivel de implementación sólida. 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 procesos menos confiables a información confidencial. MIC define cinco niveles de integridad: bajo, medio, alto, sistema e instalador confiable. [8] De forma predeterminada, los procesos comenzaron en IL medio. Los procesos elevados reciben un alto IL. [9] Los procesos secundarios, de forma predeterminada, heredan la integridad de sus padres, aunque el proceso principal puede iniciarlos con un IL más bajo. Por ejemplo, Internet Explorer 7 inicia sus subprocesos con IL bajo. Windows controla el acceso a objetos basándose en IL. Los objetos con nombre , incluidos archivos , claves de registro u otros procesos e hilos , tienen una entrada en su ACL que indica el IL mínimo del proceso que puede utilizar el objeto. MIC exige que un proceso pueda escribir o eliminar un objeto solo cuando su IL es igual o superior al IL del objeto. Además, para evitar el acceso a datos confidenciales en la memoria, los procesos no pueden abrir procesos con un IL superior para acceso de lectura . [10]
Apple Inc. ha incorporado una implementación del framework 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 limitada de alto nivel. [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 de Unix tienen MAC para CPU (multianillo), disco y memoria. Si bien es posible que el software del sistema operativo no administre 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 necesaria ]
RSBAC (control de acceso basado en conjuntos de reglas) de Amon Ott proporciona un marco para los kernels de Linux que permite varios módulos de decisiones/políticas de seguridad diferentes. Uno de los modelos implementados es el modelo de Control de Acceso Obligatorio. Un objetivo general del diseño del RSBAC era intentar alcanzar el nivel B1 (obsoleto) del Libro Naranja (TCSEC). El modelo de control de acceso obligatorio utilizado en RSBAC es prácticamente 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 EE. UU. con clasificación B1/TCSEC). RSBAC requiere un conjunto de parches para el kernel original, que el propietario del proyecto mantiene bastante bien .
Smack (Kernel de control de acceso obligatorio simplificado) es un módulo de seguridad del kernel de Linux que protege los datos y la interacción de procesos de manipulación maliciosa utilizando 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 la versión Linux 2.6.25. [15]
TOMOYO Linux es una implementación MAC liviana para Linux y Embedded Linux , desarrollada por NTT Data Corporation . Se fusionó en la versión 2.6.30 de la línea principal del kernel de Linux 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 rutas , separando los dominios de seguridad según el historial de invocaciones de procesos. que describe el comportamiento del sistema. Las políticas se describen en términos de nombres de rutas. Un dominio de seguridad se define simplemente mediante una cadena de llamadas de proceso y se representa mediante una cadena. Hay 4 modos: deshabilitado, aprendiendo , permisivo, haciendo cumplir. Los administradores pueden asignar diferentes modos para diferentes dominios. TOMOYO Linux introdujo el modo "aprendizaje", en el que los accesos ocurridos en el kernel se analizan y almacenan automáticamente para generar una política MAC: este modo podría ser el primer paso en la redacción de políticas, facilitando su personalización posterior.
SUSE Linux y Ubuntu 7.10 han agregado 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 del kernel que permite que los módulos del código del kernel gobiernen 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 admite el control de acceso obligatorio , implementado como parte del proyecto TrustedBSD. Fue introducido en FreeBSD 5.0. Desde 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 .
Trusted Solaris de Sun utiliza un mecanismo de control de acceso (MAC) obligatorio y aplicado por el sistema, donde se utilizan autorizaciones y etiquetas para hacer cumplir una política de seguridad. Sin embargo, tenga en cuenta que la capacidad de administrar 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 necesaria ] sólidamente protegidos 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 el usuario trabaja en la sesión. El acceso a la información, los programas y los dispositivos está débilmente controlado [ cita necesaria ] .