En seguridad informática , el control de acceso obligatorio ( MAC ) se refiere a un tipo de control de acceso mediante el cual el sistema operativo o la base de datos limita la capacidad de un sujeto o iniciador para acceder o, en general, realizar algún tipo de operación en un objeto o destino . [1] En el caso de los sistemas operativos, un tema suele ser un proceso o hilo; los objetos son construcciones como archivos, directorios, TCP / UDPpuertos, segmentos de memoria compartida, dispositivos IO, etc. Cada sujeto y objeto tiene un conjunto de atributos de seguridad. Siempre que un sujeto intenta acceder a un objeto, una regla de autorización impuesta por el kernel del sistema operativo examina estos atributos de seguridad y decide si el acceso puede tener lugar. Cualquier operación realizada por cualquier sujeto en cualquier objeto se prueba con el conjunto de reglas de autorización (también conocidas como política ) para determinar si la operación está permitida. Un sistema de gestión de bases de datos , en su mecanismo de control de acceso, también puede aplicar un control de acceso obligatorio; en este caso, los objetos son tablas, vistas, procedimientos, etc.
Con control de acceso obligatorio, esta política de seguridad está controlada de forma centralizada por un administrador de políticas de seguridad; los usuarios no tienen la capacidad de 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 gobierna la capacidad de los sujetos para acceder a los objetos, permite a los usuarios la capacidad de tomar decisiones políticas y / o asignar atributos de seguridad. (El sistema Unix tradicional de usuarios, grupos y permisos de lectura, escritura y ejecución es un ejemplo de DAC). Los sistemas habilitados para MAC permiten a los administradores de políticas implementar políticas de seguridad en toda la organización. Bajo MAC (y a diferencia de DAC), los usuarios no pueden anular o modificar esta política, ya sea accidental o intencionalmente. Esto permite a los administradores de seguridad definir una política central que se garantiza (en principio) que se aplicará a todos los usuarios.
Histórica y tradicionalmente, MAC se ha asociado estrechamente 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, sin embargo, MAC se ha desviado del nicho MLS y ha comenzado a ser 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 concentrarse en problemas como ataques a la red y malware sin el rigor o las limitaciones de MLS.
Antecedentes históricos e implicaciones para la seguridad multinivel
Históricamente, MAC estuvo fuertemente asociado con la seguridad multinivel (MLS) como un medio para proteger la información clasificada de EE. UU. El Trusted Computer System Evaluation Criteria (TCSEC), el trabajo fundamental sobre el tema, proporcionó la definición original de MAC como "un medio de restringir el acceso a los 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, USAF SACDIN, NSA Blacker 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 sólida.
El término 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 pueden 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 para información clasificada de EE. UU. . Se supone que el cumplimiento es más imperativo que para las aplicaciones comerciales. Esto excluye la aplicación mediante mecanismos de mejor esfuerzo; Solo los mecanismos que pueden proporcionar una aplicación absoluta o casi absoluta del mandato son aceptables para MAC. Esta es una tarea difícil y, a veces, asumida como poco realista por aquellos que no están familiarizados con las estrategias de alta seguridad, y muy difícil para aquellos que sí lo están.
Fuerza
Grados
En algunos sistemas, los usuarios tienen la autoridad para decidir si otorgan acceso a cualquier otro usuario. Para permitir eso, todos los usuarios tienen autorización para todos los datos. Esto no es necesariamente cierto en 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 el sistema para hacer cumplir 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 más robustez para entornos de sistema que contienen información secreta clasificada 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 produjo una estandarización de referencia histórica que cuantifica las capacidades de robustez de la seguridad de los sistemas y las asigna a los grados de confianza garantizados para varios 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.
Evaluación
Los Criterios Comunes [4] se basan en esta ciencia y su intención es 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 objetiva, solo se conservaron fielmente los niveles de EAL. En un caso, el nivel TCSEC C2 [5] (no es una categoría con capacidad MAC) se conservó con bastante fidelidad en los Criterios Comunes, como el Perfil de Protección de Acceso Controlado (CAPP). [6] Perfiles de protección de seguridad multinivel (MLS) (como MLSOSPP similar a B2) [7] es más general que B2. Están en conformidad con 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 una mayor flexibilidad subjetiva para decidir si las características técnicas del producto evaluado logran adecuadamente el objetivo, erosionando potencialmente la consistencia de los productos evaluados y facilitando 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.
Tal 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 (por ejemplo) puede incluir una aplicación no confiable donde el sistema debe monitorear y / o controlar los accesos a dispositivos y archivos).
Implementaciones
Algunas implementaciones de MAC, como el proyecto Blacker de Unisys , fueron certificadas lo suficientemente sólidas como para separar Top Secret de Unclassified a fines del último milenio. Su tecnología subyacente se volvió obsoleta y no se actualizaron. En la actualidad, no existen implementaciones certificadas por TCSEC a ese nivel de implementación robusta. Sin embargo, existen algunos productos menos robustos.
- 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 políticas / decisiones 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 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 de stock, que el propietario del proyecto mantiene bastante bien.
- Un proyecto de investigación de la NSA llamado SELinux agregó una arquitectura de control de acceso obligatorio al kernel de Linux , que se fusionó con la versión principal de Linux en agosto de 2003. Utiliza una característica del kernel de Linux 2.6 llamada LSM (interfaz de módulos de seguridad de Linux). Red Hat Enterprise Linux versión 4 (y versiones posteriores) vienen con un kernel habilitado para SELinux. Aunque SELinux es capaz de restringir todos los procesos en el sistema, la política de destino predeterminada en RHEL confina los programas más vulnerables del dominio no confinado en el que se ejecutan todos los demás programas. RHEL 5 incluye otros 2 tipos de políticas binarias: estricta , que intenta implementar el mínimo privilegio , y MLS , que se basa en estricta y agrega etiquetas MLS . RHEL 5 contiene mejoras adicionales de MLS y recibió 2 certificaciones LSPP / RBACPP / CAPP / EAL4 + en junio de 2007. [8]
- TOMOYO Linux es una implementación MAC liviana para Linux y Linux embebido , desarrollada por NTT Data Corporation . Se ha fusionado en la versión 2.6.30 de la línea principal del Kernel de Linux en junio de 2009. [9] A diferencia del enfoque basado en etiquetas utilizado por SELinux , TOMOYO Linux realiza un control de acceso obligatorio basado en el nombre de ruta , separando los dominios de seguridad de acuerdo con el historial de invocaciones del proceso, que describe el comportamiento del sistema. La política se describe en términos de nombres de ruta. Un dominio de seguridad se define simplemente mediante una cadena de llamadas de proceso y se representa mediante una cadena. Hay 4 modos: discapacitado, aprendizaje , permisivo y obligatorio. Los administradores pueden asignar diferentes modos para diferentes dominios. TOMOYO Linux introdujo el modo de "aprendizaje", en el que los accesos ocurridos en el kernel se analizan y almacenan automáticamente para generar la política MAC: este modo podría ser el primer paso de la redacción de la política, facilitando la personalización posterior.
- SUSE Linux y Ubuntu 7.10 han agregado una implementación de MAC llamada AppArmor . AppArmor utiliza una función del kernel de Linux 2.6 llamada LSM (interfaz de módulos de seguridad de Linux). LSM proporciona una API de kernel que permite que módulos de código de kernel controlen 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. [10]
- Linux y muchas otras distribuciones de Unix tienen MAC para CPU (multi-ring), 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 son de Unix. Los distribuidores de Linux deshabilitan MAC para que sea el mejor DAC para algunos dispositivos, aunque esto es cierto para cualquier dispositivo electrónico de consumo disponible en la actualidad.
- grsecurity es un parche para el kernel de Linux que proporciona una implementación MAC (precisamente, es una implementación RBAC ). grsecurity no se implementa a través de la API de LSM . [11]
- Microsoft A partir de Windows Vista y Server 2008, Windows incorpora el control de integridad obligatorio , que agrega niveles de integridad (IL) a los procesos que se ejecutan en una sesión de inicio de sesión. MIC restringe los permisos de acceso de las aplicaciones que se ejecutan bajo la misma cuenta de usuario y que pueden ser menos confiables. Se definen cinco niveles de integridad: Bajo, Medio, Alto, Sistema e Instalador de confianza. [12] Los procesos iniciados por un usuario regular obtienen un IL Medio; los procesos elevados tienen IL alta. [13] Si bien los procesos heredan el nivel de integridad del proceso que lo generó, el nivel de integridad se puede personalizar por proceso: por ejemplo, IE7 y los ejecutables descargados se ejecutan con Low IL. Windows controla el acceso a objetos basados en IL, así como para definir el límite de los mensajes de ventana a través del aislamiento de privilegios de la interfaz de usuario . Los objetos con nombre , incluidos archivos , claves de registro u otros procesos y subprocesos , tienen una entrada en la ACL que rige el acceso a ellos que define el IL mínimo del proceso que puede utilizar el objeto. MIC obliga a que un proceso pueda escribir o eliminar un objeto solo cuando su IL es 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 el acceso de lectura. [14]
- FreeBSD admite el control de acceso obligatorio , implementado como parte del proyecto TrustedBSD. Fue introducido en FreeBSD 5.0. Desde FreeBSD 7.2, el soporte MAC está habilitado por defecto. 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 reforzado por el sistema, en el que 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 kernel para operar en modo de seguridad multinivel [ cita requerida ] . El acceso a las etiquetas y los mecanismos de control no están [ cita requerida ] robustamente protegidos contra la corrupción en el dominio protegido mantenido por un kernel. 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 se controla débilmente [ cita requerida ] .
- El marco MAC Mac OS X de Apple es una implementación del marco MAC TrustedBSD . [15] La función de línea de comandos sandbox_init proporciona una interfaz limitada de espacio aislado de alto nivel. Consulte la página de manual de sandbox_init para obtener documentación. [dieciséis]
- Oracle Label Security es una implementación de control de acceso obligatorio en Oracle DBMS .
- SE-PostgreSQL es un trabajo en progreso desde 2008-01-27, [17] [18] que proporciona integración en SE-Linux. Su objetivo es la integración en la versión 8.4, junto con restricciones a nivel de fila.
- Trusted RUBIX es un control de acceso obligatorio que hace cumplir DBMS que se integra completamente con SE-Linux para restringir el acceso a todos los objetos de la base de datos. [19]
- El sistema operativo Astra Linux desarrollado para Russian Army tiene su propio control de acceso obligatorio. [20]
- 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 del proceso de la manipulación maliciosa mediante un conjunto de reglas de control de acceso obligatorias personalizadas, con la simplicidad como su principal objetivo de diseño. [21] Se ha fusionado oficialmente desde el lanzamiento de Linux 2.6.25. [22]
- ZeroMAC escrito por Peter Gabor Gyulay es un parche del kernel de Linux LSM. [23]
Ver también
- Modelo Bell – LaPadula
- Lista de control de acceso
- Control de acceso basado en atributos (ABAC)
- Control de acceso basado en contexto (CBAC)
- Control de acceso discrecional (DAC)
- Control de acceso basado en celosía (LBAC)
- Control de acceso basado en organización (OrBAC)
- Control de acceso basado en roles (RBAC)
- Control de acceso basado en reglas (RSBAC)
- Seguridad basada en capacidad
- Autenticación basada en la ubicación
- Autenticación basada en riesgos
- Modelo de Clark – Wilson
- Información clasificada
- Modelo de Graham-Denning
- Control de integridad obligatorio
- Múltiples de un solo nivel
- Modos de seguridad
- Smack (software)
- Systrace
- Modelo de protección de aceptación de subvenciones
- Ejecución de tipo
Notas al pie
- ^ Belim, SV; Belim, S. Yu. (Diciembre de 2018). "Implementación de Control de Acceso Obligatorio en Sistemas Distribuidos" . Control Automático y Ciencias de la Computación . 52 (8): 1124–1126. doi : 10.3103 / S0146411618080357 . ISSN 0146-4116 .
- ^ http://csrc.nist.gov/publications/history/dod85.pdf
- ^ "Racional técnico detrás de CSC-STD-003-85: Requisitos de seguridad informática" . 1985-06-25. Archivado desde el original el 15 de julio de 2007 . Consultado el 15 de marzo de 2008 .
- ^ "El portal Common Criteria" . Archivado desde el original el 18 de julio de 2006 . Consultado el 15 de marzo de 2008 .
- ^ Departamento de Defensa de Estados Unidos (diciembre de 1985). "DoD 5200.28-STD: criterios de evaluación del sistema informático de confianza" . Consultado el 15 de marzo de 2008 .
- ^ "Perfil de protección de acceso controlado, versión 1.d" . Agencia de Seguridad Nacional. 1999-10-08. Archivado desde el original el 7 de febrero de 2012 . Consultado el 15 de marzo de 2008 .
- ^ "Perfil de protección para sistemas operativos multinivel en entornos que requieren una robustez media, versión 1.22" (PDF) . Agencia de Seguridad Nacional. 2001-05-23 . Consultado el 6 de octubre de 2018 .
- ^ Asociación Nacional de Garantía de la Información. "Lista de productos validados del esquema de validación y evaluación de criterios comunes" . Archivado desde el original el 14 de marzo de 2008 . Consultado el 15 de marzo de 2008 .
- ^ "TOMOYO Linux, un control de acceso obligatorio alternativo" . Linux 2 6 30 . Principiantes del kernel de Linux.
- ^ "Linux 2.6.36 lanzado el 20 de octubre de 2010" . Linux 2.6.36 . Principiantes del kernel de Linux.
- ^ "¿Por qué grsecurity no usa LSM?" .
- ^ Matthew Conover. "Análisis del modelo de seguridad de Windows Vista" . Symantec Corporation . Archivado desde el original el 25 de marzo de 2008 . Consultado el 8 de octubre de 2007 .
- ^ Steve Riley. "Control de integridad obligatorio en Windows Vista" . Consultado el 8 de octubre de 2007 .
- ^ Mark Russinovich . "PsExec, Control de cuentas de usuario y límites de seguridad" . Consultado el 8 de octubre de 2007 .
- ^ Proyecto TrustedBSD. "Marco de control de acceso obligatorio (MAC) de TrustedBSD" . Consultado el 15 de marzo de 2008 .
- ^ "página de manual de sandbox_init (3)" . 2007-07-07 . Consultado el 15 de marzo de 2008 .
- ^ "Parche SEPostgreSQL" .
- ^ "PostgreSQL de seguridad mejorada" .
- ^ "RUBIX de confianza" . Archivado desde el original el 21 de noviembre de 2008 . Consultado el 23 de marzo de 2020 .
- ^ (en ruso) Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации Archivado el 16 de julio de 2014 en Wayback Machine
- ^ "Documentación oficial de SMACK del árbol de fuentes de Linux" . Archivado desde el original el 1 de mayo de 2013.
- ^ Jonathan Corbet. "Más cosas para 2.6.25" . Archivado desde el original el 2 de noviembre de 2012.
- ^ "zeromac.uk" .
Referencias
- PA Loscocco, SD Smalley, PA Muckelbauer, RC Taylor, SJ Turner y JF Farrell. La inevitabilidad del fracaso: la suposición defectuosa de la seguridad en los entornos informáticos modernos . En Proceedings of the 21st National Information Systems Security Conference, páginas 303–314, octubre de 1998.
- PA Loscocco, SD Smalley, Cumplimiento de los objetivos críticos de seguridad con las actas de Linux con seguridad mejorada del Simposio de Linux de Ottawa de 2001.
- ISO / IEC DIS 10181-3, Tecnología de la información, Modelo de seguridad OSI, Security FrameWorks, Parte 3: Control de acceso, 1993
- Robert NM Watson. " Una década de extensibilidad del control de acceso del sistema operativo ". Comun. ACM 56, 2 (febrero de 2013), 52–63.
enlaces externos
- Publicación en el weblog sobre cómo se puede utilizar la virtualización para implementar el control de acceso obligatorio.
- Publicación en el weblog de un empleado de Microsoft que detalla el control de integridad obligatorio y en qué se diferencia de las implementaciones de MAC.
- Modelo de política de seguridad formal de GWV Una política de seguridad formal de núcleo de separación, David Greve, Matthew Wilding y W. Mark Vanfleet.