Control de Acceso Obligatorio (MAC): decide el sistema, no tú

La denegación de las tres de la mañana

A David le llaman a las tres de la mañana. Un atacante ha aprovechado un plugin vulnerable del servidor web público de la empresa y tiene una shell que corre con la cuenta del servidor web. En los logs, David puede ver lo que pasó después. El atacante se puso a husmear por el sistema de ficheros e intentó leer un directorio de exportaciones de RR. HH. que, por un error antiguo, era legible por el grupo del servidor web. Los permisos de Linux lo habrían permitido. La lectura falló de todos modos, y a su lado, en el registro de auditoría, había una línea que empezaba por avc: denied. SELinux nunca le había dado al proceso del servidor web nada que hacer con ficheros de ese tipo, y ningún permiso de fichero podía cambiarlo.

Eso es el control de acceso obligatorio (MAC) en acción. El artículo anterior terminaba con el pecado original del DAC: decide el dueño, así que la información va adonde la mande un dueño, o un programa que corre con sus derechos. Un caballo de Troya filtra un fichero sensible y el DAC no ve nada raro, porque el acceso estaba autorizado. Para la mayoría de los datos de negocio, es un precio aceptable a cambio de comodidad. Pero hay información que no debe moverse, quiera quien quiera enviarla, y para eso hace falta un modelo en el que el propio criterio desaparezca.

El MAC le da la vuelta a la pregunta que define al DAC. El DAC pregunta qué quiere el dueño; el MAC pregunta qué permite la clasificación, y los deseos del dueño simplemente no forman parte de la respuesta. Un general dueño de un documento Alto Secreto no puede mandarlo por correo a un administrativo sin habilitación, no porque le falte permiso para enviar correos, sino porque el sistema prohíbe ese flujo de información y nadie por debajo del responsable de seguridad puede saltarse la regla. El acceso lo decide una política central, para todo el sistema, basada en etiquetas, y es obligatorio porque se impone, no se elige. El modelo nació en la defensa y la inteligencia y se formalizó en el mismo Libro Naranja de 1985 que bautizó al DAC, pero como muestra la noche de David, también funciona en servidores Linux, en tu móvil y en el entorno aislado de tu navegador.

Etiquetas: habilitaciones y clasificaciones

La maquinaria del MAC empieza con las etiquetas. Cada sujeto, un usuario o un proceso que actúa en su nombre, lleva una habilitación (clearance). Cada objeto, un fichero, un mensaje, un registro, lleva una clasificación. El sistema compara ambas en cada acceso. En el esquema gubernamental clásico, una etiqueta tiene dos partes. Una es un nivel jerárquico, la escalera conocida de No clasificado, Confidencial, Secreto y Alto Secreto, cada uno estrictamente más sensible que el anterior. La otra es un conjunto de compartimentos no jerárquicos, como NUCLEAR, CRYPTO, HR o FINANCE, que expresan la necesidad de conocer. Una etiqueta es la pareja, por ejemplo (Secreto, {CRYPTO, NUCLEAR}).

El acceso exige que la etiqueta del sujeto domine a la del objeto: el nivel del sujeto tiene que ser al menos igual de alto y sus compartimentos tienen que incluir todos los del objeto. Alguien habilitado (Alto Secreto, {CRYPTO}) no puede leer un documento (Secreto, {NUCLEAR}). Su nivel es suficiente, pero le falta el compartimento NUCLEAR. Las etiquetas forman un retículo, un orden parcial en el que algunas parejas simplemente no se pueden comparar, y esa estructura es lo que permite al MAC aplicar la necesidad de conocer además del nivel de clasificación. Es mucho más preciso que una única escalera.

Hay una sutileza que pilla a los recién llegados: la habilitación de un sujeto, lo máximo con lo que se confía en él, no es lo mismo que el nivel al que está trabajando en ese momento. Una analista habilitada para Alto Secreto puede entrar en una sesión de Secreto para trabajar con material Secreto, y mientras está ahí las reglas de no escribir abajo la tratan como sujeto Secreto. Los sistemas que dejan a un sujeto trabajar a su nivel máximo y registran en silencio lo más alto que ha tocado usan una marca de agua alta (high-water mark), que sube el nivel efectivo a medida que lee hacia arriba, algo sencillo pero que tiende a sobreclasificar todo lo que viene después.

Una habilitación tampoco es un rol. Dice cuán sensible es la información que se te confía, con independencia de lo que necesite tu trabajo, y los compartimentos la estrechan más. Esa separación entre confianza y función es la razón de que el MAC y el RBAC acaben combinados en los sistemas reales de alta seguridad: el RBAC decide qué te deja hacer tu trabajo y el MAC decide qué te deja ver tu habilitación.

Bell-LaPadula: no leer arriba, no escribir abajo

Las etiquetas dicen en quién se confía para qué, pero lo ingenioso del MAC está en las reglas de flujo que las usan. El modelo de referencia es Bell-LaPadula, construido en los años 70 para proteger la confidencialidad, y tiene dos reglas engañosamente sencillas.

La primera es no leer arriba, también llamada propiedad de seguridad simple. Un sujeto no puede leer un objeto clasificado por encima de su habilitación, así que un usuario Confidencial no puede abrir un fichero Secreto. Es la regla obvia, la razón de que existan las habilitaciones. La segunda es no escribir abajo, la propiedad estrella, que se escribe *-property. Un sujeto no puede escribir en un objeto clasificado por debajo de su habilitación, así que un proceso Alto Secreto no puede escribir en un fichero No clasificado. Es la regla que nadie espera, y es toda la clave: impide que la información clasificada baje hacia quien no está habilitado para verla.

Quédate con la segunda regla, porque es la que cierra el hueco que dejó el DAC. Recuerda el caballo de Troya: David le da a Sara un programa que lee un fichero sensible y lo copia en un sitio al que David puede llegar. Con Bell-LaPadula, el proceso de Sara corre al nivel sensible, así que no puede escribir abajo en ningún lugar que David, de un nivel inferior, pueda leer. El sistema bloquea la fuga intente lo que intente el programa de Sara y permita lo que permita cualquier dueño. El MAC controla el flujo de la información, no solo el acceso, y esa es la capacidad que al DAC le falta de raíz. Dicho como lema: leer abajo y escribir arriba están permitidos; leer arriba y escribir abajo, no.

---
config:
  flowchart:
    rankSpacing: 80
    nodeSpacing: 55
---
flowchart TD
  accTitle: Reglas de no leer arriba y no escribir abajo de Bell-LaPadula
  accDescr: Un sujeto habilitado en el nivel Secreto se ramifica hacia sus cuatro operaciones posibles. Escribir en un objeto Alto Secreto (escribir arriba) está permitido. Leer un objeto Alto Secreto (leer arriba) está denegado. Leer un objeto No clasificado (leer abajo) está permitido. Escribir en un objeto No clasificado (escribir abajo) está denegado. Las operaciones permitidas se dibujan con flechas continuas y las denegadas con flechas punteadas. El efecto neto es que la información solo puede fluir hacia arriba, hacia una clasificación más alta.
  SUBJ["Sujeto habilitado: Secreto"]
  SUBJ --> WU["Objeto Alto Secreto<br/>escribir arriba: PERMITIDO"]
  SUBJ -.-> RU["Objeto Alto Secreto<br/>leer arriba: DENEGADO"]
  SUBJ --> RD["Objeto No clasificado<br/>leer abajo: PERMITIDO"]
  SUBJ -.-> WD["Objeto No clasificado<br/>escribir abajo: DENEGADO"]

Dos refinamientos hacen que Bell-LaPadula funcione en la práctica. El principio de tranquilidad dice que las etiquetas no deben cambiar mientras se usan; la tranquilidad fuerte lo prohíbe del todo y la débil permite cambios que no rompan las reglas, porque una etiqueta que cambia a mitad de una operación puede abrir una fuga sin que nadie lo note. Y como un no escribir abajo puro haría imposible desclasificar o resumir nada, los sistemas reales designan unos pocos sujetos de confianza, procesos o responsables muy examinados a los que se permite bajar información bajo una revisión controlada. Son las excepciones deliberadas y auditadas que mantienen utilizable un modelo rígido, y que haya que designarlos y confiar en ellos muestra lo en serio que se toma el MAC el flujo hacia abajo.

Biba: el espejo de la integridad

Bell-LaPadula protege el secreto, que los datos no se filtren hacia abajo. A veces lo que importa es lo contrario: que unos datos de poca calidad no corrompan datos de alta integridad. Eso es la integridad, y el modelo Biba es Bell-LaPadula puesto del revés. Sus reglas son el reflejo exacto del original: no leer abajo, para no leer datos menos fiables que tú y dejar que contaminen tu razonamiento, y no escribir arriba, para no escribir en datos más fiables que tú. Donde Bell-LaPadula hace que la información suba hacia el secreto, Biba hace que baje hacia zonas de menos confianza, para que los datos fiables sigan limpios.

Biba es en esencia como funciona el Mandatory Integrity Control de Windows, y explica por qué un proceso de baja integridad, como una pestaña aislada del navegador, no puede escribir en ubicaciones del sistema de alta integridad. La confidencialidad y la integridad son preocupaciones gemelas, y el MAC tiene un modelo para cada una. Los sistemas reales a menudo quieren las dos a la vez, lo que se complica enseguida, y es una de las razones de que la seguridad multinivel pura sea rara fuera de la defensa mientras el MAC dirigido está en todas partes.

Más allá del secreto: Clark-Wilson y la Muralla China

Bell-LaPadula y Biba son la pareja famosa, pero la familia MAC tiene modelos para preocupaciones que ellos no recogen. Clark-Wilson se centra en la integridad comercial. En lugar de niveles, exige que los datos solo cambien mediante transacciones bien formadas ejecutadas por programas certificados, y que las funciones estén separadas para que nadie pueda a la vez hacer un cambio y aprobarlo. Es el antepasado formal de “no puedes aprobar tu propia nota de gastos”, la segregación de funciones que el RBAC lleva a la práctica en el siguiente artículo.

El modelo de la Muralla China, también llamado Brewer-Nash, recoge los conflictos de interés, que son dinámicos de una forma en que los niveles no lo son. Un consultor puede consultar los datos de un banco; en cuanto lo hace, la política tiene que impedirle tocar los datos de un banco competidor. Acceder a un lado de la muralla te cierra el otro, según tu historial, y eso no lo puede expresar ninguna habilitación estática. Estos modelos muestran que el MAC no va solo de secretos militares: la misma idea de una política impuesta por el sistema y no discrecional sirve para la integridad financiera y los conflictos de interés, y esas ideas vuelven más adelante en el control basado en políticas y en atributos.

El MAC en la práctica: SELinux

El sistema MAC más desplegado del mundo viene en todos los móviles Android y en la mayoría de los servidores Linux de empresa: SELinux, Security-Enhanced Linux, desarrollado originalmente por la NSA y hoy parte del núcleo principal. No trata sobre todo de niveles de clasificación militar. Su caballo de batalla es el control por tipos (type enforcement): cada proceso corre en un dominio, cada objeto tiene un tipo y una política central dice exactamente qué dominios pueden actuar sobre qué tipos. Un servidor web en el dominio httpd_t puede leer ficheros del tipo httpd_content_t y nada más, aunque los permisos del DAC permitieran más.

Ese “aunque el DAC permitiera más” es la esencia del MAC, y es lo que salvó la noche de David. Cuando el servidor web comprometido intentó leer las exportaciones de RR. HH., los permisos de Linux jugaban a favor del atacante, pero la política de SELinux nunca le había dado a httpd_t ningún acceso a ese tipo, así que el núcleo se negó. Un dueño no puede salir de ahí con un chmod; la política es obligatoria. Por eso SELinux es una herramienta de contención tan potente: encierra a un proceso comprometido en exactamente lo que su función necesita de verdad, que es el principio de “asume que ya te han comprometido” de Zero Trust aplicado al sistema operativo.

Todo lo que tiene etiqueta en SELinux lleva un contexto, escrito usuario:rol:tipo:nivel, por ejemplo system_u:object_r:httpd_content_t:s0, y ls -Z o ps -Z te los muestran. Los cuatro campos revelan que SELinux junta tres modelos de control de acceso a la vez: el control por tipos, el de uso diario; una capa de RBAC que limita a qué tipos puede llegar un rol; y una capa MLS opcional, el nivel s0, para despliegues multinivel al estilo de Bell-LaPadula. La mayoría de los sistemas usan el control por tipos y dejan el MLS apagado, y por eso “SELinux es clasificación militar” es una idea común pero equivocada.

SELinux funciona en uno de tres modos: enforcing, que deniega y registra; permissive, que permite pero registra lo que habría denegado, algo valiosísimo al desarrollar políticas; y disabled. Como una política equivocada bloquea trabajo legítimo con denegaciones AVC crípticas, los operadores cansados tiran de setenforce 0 para pasar a modo permisivo y muchas veces nunca lo vuelven a activar, tirando a la basura toda la capa obligatoria. El camino disciplinado es leer la denegación, generar un ajuste de política concreto, por ejemplo con audit2allow, y seguir en modo enforcing. Apagar el MAC para que desaparezca un error es la forma más común de que una organización pierda sin enterarse la protección que había desplegado.

El MAC en todas partes

Cuando conoces su forma, el MAC aparece por toda la informática moderna. AppArmor, el predeterminado en Ubuntu y SUSE, es un MAC basado en rutas que encierra a los programas en las rutas y capacidades que se declaran, más sencillo que SELinux pero con el mismo principio obligatorio. El Mandatory Integrity Control de Windows marca los procesos con niveles de integridad, Low, Medium, High y System, y prohíbe que el código de baja integridad escriba en objetos de integridad mayor. Es Biba en producción, y la razón de que un navegador aislado o un fichero descargado se ejecuten en Low y no puedan manipular tu sistema.

Los entornos aislados de las apps de iOS y Android también son MAC: una política del sistema encierra a cada app en sus propios datos y en un conjunto declarado de permisos, y ninguna app, por mucho que quiera su desarrollador, puede llegar al almacenamiento privado de otra. Los contenedores y los hipervisores se apoyan en perfiles de SELinux o AppArmor para que un contenedor comprometido no escape al anfitrión. Hasta el aislamiento de sitios de tu navegador se comporta como MAC, una frontera obligatoria que los propios sitios no pueden negociar.

Lo que cambió entre los fallidos ordenadores centrales multinivel y los entornos aislados de hoy es quién pone las etiquetas. El MAC clásico pedía a las personas que clasificaran los datos, algo lento y propenso a errores. El MAC dirigido moderno etiqueta componentes de software, esta app, ese servicio, este contenedor, algo que un desarrollador o una distribución puede definir una vez y publicar. La política sigue siendo obligatoria y el usuario final sigue sin poder saltársela, pero la carga pasó de clasificar a mano cada documento a declarar qué puede tocar cada programa, y ese cambio permitió que el control obligatorio saliera del nicho de defensa y se convirtiera en infraestructura invisible y por defecto en miles de millones de dispositivos.

La seguridad multinivel y por qué el MAC no conquistó el mundo

Ejecutar de verdad niveles de clasificación distintos en un mismo sistema, la seguridad multinivel (MLS), es uno de los problemas más difíciles de la seguridad, y su historia invita a la humildad. En los años 80 y 90, los fabricantes construyeron sistemas operativos y bases de datos MLS evaluados en las exigentes clases B1 a A1 del Libro Naranja, y casi todos fracasaron comercialmente. Eran caros, lentos de certificar y penosos de usar, y el mercado para una máquina que manejara con seguridad Secreto y No clasificado a la vez fue más pequeño de lo esperado. El MLS completo se quedó en la defensa y la inteligencia, y sus ideas se reempaquetaron en el MAC dirigido y más ligero que se usa hoy.

Cuando la información tiene que cruzar niveles de verdad, los sistemas de defensa usan una solución entre dominios o guarda, un componente pequeño y muy verificado cuyo único trabajo es mover datos entre una red alta y una baja con reglas estrictas, inspeccionando y limpiando cada transferencia. Y para frenar una fuga sutil en la que la mera existencia de un registro de alto nivel revela algo clasificado, las bases de datos MLS usan la poliinstanciación: dos registros pueden compartir la misma clave, uno visible en cada nivel, de modo que un usuario con habilitación baja que consulta un hueco aparentemente libre nunca se entera de que un registro de nivel alto ya lo ocupa. Son mecanismos exóticos, pero muestran lo profundo que llega el compromiso de controlar el flujo, y no solo el acceso, cuando está en juego la seguridad nacional.

Si el MAC es estrictamente más fuerte que el DAC, ¿por qué el modelo principal de tu portátil sigue siendo discrecional? Porque las garantías sin usabilidad no sobreviven al trabajo real. La rigidez que bloquea el caballo de Troya bloquea también a la analista que necesita, con todo derecho, pasar un gráfico de una presentación clasificada a un informe no clasificado, y cada uno de esos roces se convierte en presión para debilitar, sortear o apagar la política. La historia premió los modelos que la gente realmente mantenía activados. Por eso el MAC moderno se volvió dirigido: en lugar de clasificarlo todo, SELinux y AppArmor encierran un puñado de servicios de alto riesgo, como servidores web y contenedores, y dejan el resto del sistema en el DAC de siempre. Consigues casi toda la contención por una fracción del coste de etiquetado.

Incluso una política de etiquetas aplicada a la perfección tiene una debilidad que queda: el canal encubierto. Bell-LaPadula impide que un proceso alto escriba abajo un fichero, pero dos procesos que se pongan de acuerdo pueden filtrar información a través de efectos secundarios que las reglas de etiquetas no gobiernan. Un proceso alto puede variar su uso de CPU o llenar un disco siguiendo un patrón que un proceso bajo observa, enviando bits sin escribir nunca nada clasificado. Estos canales de tiempo y de almacenamiento son lentos y difíciles de explotar, pero en los entornos de máxima exigencia hay que analizarlos y reducirlos. Las etiquetas controlan los flujos de información con nombre, no todos los físicos, así que el MAC sube muchísimo el listón sin llegar nunca a un absoluto.

Puntos fuertes y débiles, con honestidad

El MAC ofrece un control real sobre el flujo de la información, lo único que el DAC no puede hacer, así que resiste al caballo de Troya y al delegado confundido por estructura y no a base de vigilancia. Su política es central y coherente: la organización, y no cada dueño, fija las reglas, así que “ningún dato Secreto llega nunca a un canal No clasificado” puede aplicarse como invariante. Resiste la manipulación por diseño, porque los usuarios normales, dueños incluidos, no pueden debilitarlo. Y como capa de contención es excelente: encierra a un proceso comprometido en exactamente lo que dicen sus etiquetas.

Esa misma rigidez es el precio. Todo tiene que estar etiquetado, y bien etiquetado, y mantener las etiquetas al día a medida que se crean y transforman datos es de verdad difícil. La política central tiene que prever todos los flujos de trabajo legítimos, y cuando no lo hace, la gente choca con muros sin salida discrecional, y por eso el MAC sin cuidar acaba apagado. Es pesado de administrar y necesita perfiles especializados. Tiende a la sobreclasificación, a etiquetar más alto por si acaso, lo que luego frena la colaboración. Y ningún sistema MAC elimina del todo los canales encubiertos. El MAC compra garantías y las paga en flexibilidad y esfuerzo.

El MAC y el DAC no son alternativas. Los sistemas reales los usan juntos, y una petición tiene que superar tanto los permisos discrecionales como la política obligatoria. El DAC deja a la gente gestionar lo que comparte en el día a día, y el MAC traza las líneas duras que nada de lo compartido puede cruzar. Quitar el DAC haría los sistemas inservibles; quitar el MAC eliminaría las garantías. Los entornos de alta seguridad mantienen los dos, con el MAC como suelo innegociable.

De vuelta a la carpeta de investigación

Vuelve a la carpeta /research/roadmap de Sara del artículo del DAC, pero imagina ahora que la organización usa MAC, con la hoja de ruta clasificada como Confidencial y Daniel habilitado solo para Interno. Sara todavía puede fijar permisos discrecionales, porque el DAC sigue ahí, pero ya no tienen la última palabra. Cuando Daniel intenta abrir q3.pdf, la política obligatoria compara su habilitación con la clasificación del fichero, ve que Interno no domina a Confidencial y le deniega el acceso, tenga la ACL que tenga Sara. Y si algún programa servicial de Daniel intentara copiar el fichero a una carpeta compartida Interna, el no escribir abajo lo bloquearía, porque un proceso Confidencial no puede escribir en un objeto Interno.

La fuga que el DAC no podía impedir ahora es imposible por estructura, no porque Sara tuviera cuidado, sino porque la política del sistema hace ilegal ese flujo. Ese es todo el valor del MAC en una escena. También muestra el coste: alguien tuvo que clasificar la hoja de ruta, habilitar a Daniel y mantener al día las dos etiquetas. Nadie consigue esas garantías gratis, y por eso el MAC se usa donde lo que está en juego justifica el esfuerzo y se complementa con modelos más ligeros en todo lo demás.

Y el MAC deja algo sin resolver. Frenó la fuga, pero no dijo nada sobre por qué Daniel debería o no debería ver la hoja de ruta según su trabajo. Su habilitación trata de confianza y sensibilidad, no del hecho de que trabaje en soporte y la hoja de ruta sea de producto. Expresar con limpieza “el acceso sigue a tu trabajo”, con miles de empleados, es un problema distinto de controlar el flujo de información, y es para el que se construyó el siguiente modelo. El MAC traza la línea dura; el RBAC organiza todo lo que queda dentro.

Dónde encaja el MAC, y sus descendientes modernos

En el mapa del artículo del DAC, el MAC es la respuesta al flujo de información sin control. Funciona como un suelo obligatorio por debajo de los modelos más flexibles: el DAC se ocupa de lo que comparten los dueños, el RBAC del acceso según el puesto a escala de empresa, el ABAC del contexto y el MAC, donde existe, se impone a todos con reglas de etiquetas que nadie puede negociar. En un sistema con todas las capas, una petición tiene que cumplir la política MAC, los permisos del DAC, la comprobación de roles del RBAC y cualquier regla ABAC, y cualquier capa puede denegarla. El MAC es además el antepasado conceptual de ideas que verás más adelante: su política central que los dueños no pueden saltarse es la semilla del control de acceso basado en políticas y de las políticas como código.

Puede que nunca configures un retículo de Bell-LaPadula, pero casi seguro que trabajas dentro de sus descendientes. Los niveles de clasificación de datos que usan casi todas las empresas, Público, Interno, Confidencial, Restringido, son etiquetas MAC con otro nombre, y las herramientas que ponen una etiqueta de sensibilidad a un documento y luego se niegan a dejar que salga por correo de la empresa están aplicando, en espíritu, el no escribir abajo. La prevención de pérdida de datos (DLP) es la reencarnación comercial del control del flujo de información: inspecciona el contenido, lee o asigna una clasificación y bloquea los flujos que llevarían datos sensibles a un sitio no autorizado, aplicado al correo, las subidas y las memorias USB en lugar de a redes clasificadas. La nube resucitó estas ideas a gran escala. Cuando marcas un bucket o un conjunto de datos como sensible y una política impide que salga de una región o que se haga público, eso es control de flujo obligatorio y basado en etiquetas con vocabulario de nube, y las etiquetas de sensibilidad de Microsoft Purview, las etiquetas de AWS conectadas a las políticas de control de servicios y los VPC Service Controls de Google expresan todos “estos datos no pueden ir ahí, lo pida quien lo pida”. Hasta la computación confidencial, que mantiene los datos cifrados y aislados incluso del operador del anfitrión, lleva el instinto de etiquetar y aplicar al hardware.

Conocer este linaje es práctico. Cuando una regla de DLP te molesta bloqueando un envío legítimo, ahora puedes verla como una regla de no escribir abajo a la que le falta una excepción de sujeto de confianza, y sabes que el arreglo correcto es un camino de desclasificación controlado y auditado, no apagar la regla.

Resumen

El control de acceso obligatorio elimina el criterio propio para ganar garantías. Decide el sistema, no el dueño: una política central basada en etiquetas gobierna el acceso, y ningún usuario normal, ni siquiera el dueño, puede saltársela. Las etiquetas combinan un nivel con compartimentos y forman un retículo que aplica a la vez la sensibilidad y la necesidad de conocer, y el acceso exige que la etiqueta del sujeto domine a la del objeto. Las reglas de flujo son el núcleo: Bell-LaPadula, con no leer arriba y no escribir abajo, protege la confidencialidad y cierra el hueco del caballo de Troya, y Biba es su reflejo para la integridad. El MAC funciona discretamente en todas partes, con el control por tipos de SELinux, AppArmor, el Mandatory Integrity Control de Windows y los entornos aislados de iOS y Android, siempre por encima de permisos discrecionales. Y las garantías cuestan flexibilidad, así que el MAC es un suelo firme para los datos de alto riesgo, complementado por modelos más ligeros en lugar de sustituirlos.

Tres preguntas para ponerte a prueba

1. Usando en concreto la regla de no escribir abajo, explica por qué Bell-LaPadula frena justo la fuga del caballo de Troya que el DAC permite. ¿Qué tendría que cumplirse en el nivel de destino del atacante para que la fuga funcionara con Bell-LaPadula?
2. Un compañero dice: “Usamos SELinux, así que tenemos seguridad militar multinivel”. Corrige la confusión: ¿qué aplica realmente el control por tipos de SELinux y en qué se diferencia de los niveles de clasificación de Bell-LaPadula?
3. Tu organización quiere a la vez que los secretos no se filtren y que los datos no fiables no corrompan datos críticos. ¿Qué modelo se ocupa de cada cosa y por qué aplicar los dos a la vez puede crear exigencias de etiquetas contradictorias para un mismo sujeto?

Ejercicios prácticos

1. Mira cómo el MAC deniega algo que el DAC permitía. En un sistema con SELinux, por ejemplo una máquina virtual Fedora o RHEL, pon SELinux en modo enforcing y haz que un servicio lea un fichero fuera de su tipo permitido, por ejemplo moviendo contenido web a una ruta que no tenga la etiqueta httpd_content_t y recargando. Observa cómo aparece la denegación en el registro de auditoría aunque los permisos del DAC estén bien, y usa audit2allow para ver qué política haría falta.
2. Encuentra los niveles de integridad de tu propia máquina. En Windows, usa una herramienta como Process Explorer para ver el nivel de integridad de tu navegador y de un proceso del sistema, y comprueba que el navegador corre más bajo. En el móvil, lee los permisos declarados de una app. Relaciona lo que encuentres con el no escribir arriba de Biba.
3. Diseña un esquema de etiquetas de dos niveles. Para un pequeño conjunto de datos que conozcas, como expedientes de RR. HH. y anuncios públicos, define dos clasificaciones y dos habilitaciones, y escribe las reglas de lectura y escritura de Bell-LaPadula para un sujeto de cada nivel. Identifica un flujo de trabajo legítimo que tus reglas bloquearían y describe la excepción controlada que necesitaría un sistema MLS real para permitirlo.