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

Cuando la discreción es el riesgo

El artículo anterior terminó en el pecado original de DAC: el dueño decide, así que la información fluye a donde un dueño — o un programa que corre con los derechos del dueño — la envíe. Un caballo de Troya filtra un archivo clasificado y DAC no ve nada malo, porque el acceso estaba autorizado. Para la mayoría de los datos de negocio ese es un intercambio aceptable por comodidad. Pero cierta información no debe fluir, sin importar quién quiera enviarla, y para eso necesitas un modelo donde la discreción misma se elimine. Ese modelo es el Control de Acceso Obligatorio (MAC).

MAC da la vuelta a la pregunta definitoria de DAC. DAC pregunta “¿qué quiere el dueño?” MAC pregunta “¿qué permite la clasificación?” — y los deseos del dueño simplemente no forman parte de la respuesta. Un general que es dueño de un documento Alto Secreto no puede enviarlo por correo a un oficinista sin habilitación, no porque le falte permiso para enviar correo, sino porque el sistema prohíbe ese flujo de información y nadie por debajo del oficial de seguridad puede anular la regla. El acceso lo decide una política central de todo el sistema basada en etiquetas, y es obligatorio porque se impone, no se elige.

Este es el modelo nacido en la defensa y la inteligencia, formalizado en el mismo Libro Naranja de 1985 que nombró a DAC. Pero no lo archives bajo “solo militar” — como veremos, MAC corre silenciosamente en tu teléfono, tus servidores Linux y el sandbox del navegador en Windows. Las ideas tienen 50 años y son más relevantes que nunca.

Etiquetas: habilitaciones y clasificaciones

La maquinaria de MAC empieza con las etiquetas. Cada sujeto (un usuario, o un proceso que actúa por él) porta una habilitación. Cada objeto (un archivo, un mensaje, un registro) porta una clasificación. El sistema compara ambas en cada acceso. En el esquema gubernamental clásico las etiquetas tienen dos partes.

Un nivel jerárquico — la escalera familiar: No clasificado, luego Confidencial, luego Secreto, luego Alto Secreto, cada uno estrictamente más sensible que el anterior. Un conjunto de compartimentos no jerárquicos (también llamados categorías) — cosas como NUCLEAR, CRYPTO, RRHH, FINANZAS — que codifican la necesidad de saber. Una etiqueta es el par: (nivel, conjunto de compartimentos), por ejemplo (Secreto, {CRYPTO, NUCLEAR}).

El acceso requiere que la etiqueta del sujeto domine la del objeto: el nivel del sujeto es al menos tan alto, y el conjunto de compartimentos del sujeto incluye todos los del objeto. Alguien habilitado (Alto Secreto, {CRYPTO}) no puede leer un documento (Secreto, {NUCLEAR}) — su nivel es lo bastante alto, pero le falta el compartimento NUCLEAR. Esto es una retícula (lattice): las etiquetas forman un orden parcial donde algunos pares son simplemente incomparables, y esa estructura es lo que permite a MAC hacer cumplir la necesidad de saber encima del nivel de clasificación. Es mucho más preciso que una sola escalera.

Una sutileza confunde a los novatos: la habilitación de un sujeto (el máximo con el que se le confía) no es lo mismo que el nivel al que opera actualmente. Un analista Alto Secreto puede iniciar una sesión Secreta para trabajar en material Secreto; mientras esté ahí, las reglas de escribir-abajo lo tratan como un sujeto Secreto. Los sistemas que dejan a un sujeto correr en su máximo y rastrean silenciosamente lo más alto que ha tocado usan un enfoque de marca de agua alta (high-water-mark), que eleva el nivel efectivo a medida que lee hacia arriba — un diseño simple pero que tiende a sobre-clasificar todo aguas abajo. La distinción entre “habilitado para” y “corriendo en” es pequeña pero esencial para razonar sobre las reglas de flujo que siguen.

Bell-LaPadula: no leer arriba, no escribir abajo

Las etiquetas te dicen quién es de confianza para qué, pero el genio de MAC está en las reglas de flujo que las usan. El modelo fundacional es Bell-LaPadula (BLP), construido en los años setenta para proteger la confidencialidad. Tiene dos reglas engañosamente simples.

No leer arriba (la propiedad de seguridad simple). Un sujeto no puede leer un objeto cuya clasificación esté por encima de su habilitación. Un usuario Confidencial no puede abrir un archivo Secreto. Esta es la regla obvia — es por lo que necesitas habilitación siquiera.

No escribir abajo (la propiedad estrella, escrita *-property). Un sujeto no puede escribir en un objeto cuya clasificación esté por debajo de su habilitación. Un proceso Alto Secreto no puede escribir en un archivo No clasificado. Esta es la regla no obvia, y es todo el punto: impide que la información clasificada fluya hacia abajo hacia quienes no están habilitados para ella.

Detente en la segunda regla, porque es lo que cierra la brecha que DAC dejó abierta. Recuerda el caballo de Troya: Daniel engaña a Sara para que ejecute un programa que lee un archivo sensible y lo copia a algún lugar que Daniel puede alcanzar. Bajo BLP, el proceso de Sara corre en el nivel sensible, así que no puede escribir abajo a ninguna ubicación que Daniel (en un nivel inferior) pueda leer. La fuga la bloquea el sistema, sin importar lo que el programa de Sara intente ni lo que cualquier dueño permitiera. MAC controla el flujo de información, no solo el acceso — y esa es la capacidad de la que DAC carece fundamentalmente. Resumido como eslogan: leer abajo, escribir arriba está permitido; leer arriba y escribir abajo, no.

Dos refinamientos hacen a BLP viable en la realidad. El principio de tranquilidad dice que las etiquetas no deberían cambiar durante el uso — la “tranquilidad fuerte” lo prohíbe de plano, la “tranquilidad débil” permite cambios que no violen las reglas — porque una etiqueta que se desplaza a mitad de operación puede abrir silenciosamente una fuga. Y como el puro no-escribir-abajo haría imposible desclasificar o resumir nada, los sistemas reales designan unos pocos sujetos de confianza: procesos u oficiales cuidadosamente examinados a los que se permite mover información hacia abajo bajo revisión controlada. Esos sujetos de confianza son las excepciones deliberadas y auditadas que mantienen usable a un modelo rígido — y el hecho de que deban ser designados y de confianza es en sí un recordatorio de lo en serio que MAC toma el flujo hacia abajo.

---
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 mayor clasificación.
  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"]

Biba: el espejo de la integridad

Bell-LaPadula protege el secreto — evitar que los datos se filtren hacia abajo. Pero a veces te importa lo contrario: evitar que datos de baja calidad corrompan datos de alta integridad. Eso es la integridad, y el modelo Biba es Bell-LaPadula puesto de cabeza. Sus reglas reflejan BLP exactamente: no leer abajo (no leas datos menos confiables que tú, no sea que corrompan tu razonamiento) y no escribir arriba (no escribas en datos más confiables que tú). Donde BLP hace fluir la información hacia arriba hacia el secreto, Biba la hace fluir hacia abajo hacia zonas menos confiables, para que los datos confiables permanezcan sin contaminar.

Biba no es pieza de museo: es esencialmente cómo funciona el Control de Integridad Obligatorio de Windows, y la intuición detrás de por qué un proceso de baja integridad (digamos, una pestaña de navegador en sandbox) no puede escribir en ubicaciones del sistema de alta integridad. Confidencialidad e integridad son preocupaciones duales, y MAC tiene un modelo para cada una. Los sistemas reales a menudo quieren ambas a la vez, lo que se complica rápido — una razón por la que la seguridad multinivel pura es rara fuera de la defensa, mientras que el MAC dirigido (más abajo) está en todas partes.

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

Bell-LaPadula y Biba son el par famoso, pero la familia MAC tiene modelos para preocupaciones que ellos no capturan. Clark-Wilson apunta a la integridad comercial: en lugar de niveles, insiste en que los datos se cambien solo mediante transacciones bien formadas ejecutadas por programas certificados, y en que los deberes se separen de modo que ningún actor único pueda crear y aprobar un cambio. Es el ancestro formal de “no puedes aprobar tu propio informe de gastos” — la separación de deberes que RBAC hará práctica dos artículos más adelante.

El modelo de la Muralla China (Brewer-Nash) captura el conflicto de interés, que es dinámico de una forma que los niveles no son. Un consultor puede acceder a los datos de un banco en un mercado; en el momento en que lo hace, la política debe prohibirle tocar los datos de un banco competidor — el acceso a una muralla elimina el acceso a otra, con base en el historial. Ninguna habilitación estática expresa eso. Estos modelos importan porque muestran que MAC no trata solo del secreto militar: la misma idea de “política no discrecional impuesta por el sistema” modela la integridad financiera y el conflicto de interés, y esas ideas resurgen directamente en el control basado en políticas y basado en atributos más adelante en este módulo.

MAC en la práctica n.º 1: SELinux

El sistema MAC más desplegado de la Tierra viene en cada teléfono Android y en la mayoría de los servidores Linux empresariales: SELinux (Security-Enhanced Linux), desarrollado originalmente por la NSA y ahora parte del kernel principal. Es crucial que SELinux no trata principalmente de niveles de clasificación militar. Su caballo de batalla es el type enforcement: cada proceso corre en un dominio y cada objeto tiene un tipo, y una política central declara exactamente qué dominios pueden actuar sobre qué tipos. Un servidor web en el dominio httpd_t puede leer archivos de tipo httpd_content_t y nada más — incluso si los permisos DAC permitieran más.

Ese “incluso si DAC permitiera más” es la esencia de MAC. Si un atacante compromete el servidor web e intenta leer /etc/shadow, los permisos de Linux podrían ser engañados, pero la política de SELinux nunca concedió a httpd_t acceso a shadow_t, así que el kernel lo deniega. El dueño no puede sortearlo con chmod; la política es obligatoria. Por eso SELinux es una herramienta de contención tan poderosa: confina un proceso comprometido a exactamente lo que su rol legítimamente necesita, encarnando el “asume la brecha” de Zero Trust a nivel de sistema operativo.

Contextos y modos

Cada cosa etiquetada en SELinux porta un contexto, mostrado como usuario:rol:tipo:nivel, p. ej. system_u:object_r:httpd_content_t:s0. Ejecuta ls -Z o ps -Z y los ves. Fíjate en que el contexto tiene cuatro campos: SELinux en realidad agrupa tres modelos de control de acceso a la vez — type enforcement (el caballo de batalla cotidiano), una capa RBAC que limita qué tipos puede alcanzar un rol, y una capa MLS opcional (el nivel s0) para despliegues multinivel estilo Bell-LaPadula. La mayoría de los sistemas usan type enforcement y dejan MLS apagado, que es por qué “SELinux es igual a clasificación militar” es una suposición común pero equivocada.

SELinux corre en uno de tres modos: enforcing (denegar y registrar), permissive (permitir pero registrar lo que habría sido denegado — invaluable para desarrollar política) y disabled (apagado por completo). El modo permissive es la forma honesta de depurar una política sin perder la protección permanentemente, y la disciplina es desarrollar en permissive, luego volver a enforcing — nunca enviar con él deshabilitado.

MAC en la práctica n.º 2: en todas partes

Una vez que conoces la forma, MAC aparece por toda la computación moderna. AppArmor (por defecto en Ubuntu y SUSE) es un MAC basado en rutas que confina programas a rutas de archivo y capacidades declaradas — más simple que SELinux, mismo principio obligatorio. El Control de Integridad Obligatorio de Windows etiqueta procesos con niveles de integridad (Bajo, Medio, Alto, Sistema) y prohíbe que el código de baja integridad escriba en objetos de mayor integridad — Biba en producción, y la razón por la que un navegador en sandbox o un archivo descargado corre en “Bajo” y no puede manipular tu sistema.

Los sandboxes de apps en iOS y Android son MAC: cada app queda confinada por una política del sistema a sus propios datos y a un conjunto declarado de entitlements, y ninguna app — por mucho que su desarrollador lo desee — puede alcanzar el almacenamiento privado de otra app. Los contenedores e hipervisores se apoyan en MAC (perfiles SELinux/AppArmor) para evitar que un contenedor comprometido escape al host. Incluso el aislamiento de sitios de tu navegador es tipo MAC: una frontera obligatoria e impuesta por el sistema que los sitios mismos no pueden negociar. La idea de etiquetar-y-hacer-cumplir de la investigación de defensa de los años setenta resulta ser la columna vertebral del sandboxing moderno.

Lo que cambió entre los fallidos mainframes MLS y los ubicuos sandboxes de hoy es quién hace el etiquetado. El MAC clásico pedía a humanos clasificar datos, lo cual era lento y propenso a errores. El MAC dirigido moderno etiqueta componentes de software — esta app, ese servicio, este contenedor — que un desarrollador o distribución puede definir una vez y enviar. La política sigue siendo obligatoria e inanulable por el usuario final, pero la carga de etiquetado pasó de “clasificar cada documento a mano” a “declarar qué puede tocar cada programa”, y ese cambio es exactamente lo que permitió al control obligatorio escapar del nicho de defensa y volverse infraestructura invisible y por defecto en miles de millones de dispositivos.

Seguridad multinivel, guardias y el problema difícil

Correr niveles de clasificación genuinamente distintos en un mismo sistema — la verdadera Seguridad Multinivel (MLS) — es uno de los problemas más difíciles de la seguridad, y la historia es aleccionadora. En los años ochenta y noventa, algunos fabricantes construyeron sistemas operativos y bases de datos MLS evaluados a las estrictas clases B1/A1 del Libro Naranja; casi todos fracasaron comercialmente. Eran caros, lentos de certificar y penosos de usar, y el mercado de “una máquina que maneje con seguridad Secreto y No clasificado a la vez” era más pequeño de lo esperado. La lección moldeó el campo: el MLS completo se reserva para defensa e inteligencia, mientras que las ideas se reempaquetaron en el MAC más ligero y dirigido que de hecho se envía hoy.

Donde la información genuinamente debe cruzar niveles, los sistemas de defensa usan una solución de dominio cruzado (CDS) o guardia — un componente pequeño y fuertemente asegurado cuyo único trabajo es mover datos entre una red alta y una baja bajo reglas estrictas, inspeccionando y saneando cada transferencia. Y para detener una fuga sutil donde la mera existencia de un registro de alto nivel revela información clasificada, las bases de datos MLS usan poliinstanciación: dos registros pueden existir con la misma clave, uno visible en cada nivel, así que un usuario de baja habilitación que consulta un espacio “libre” nunca se entera de que un registro de alta habilitación lo ocupa en secreto. Estos son mecanismos exóticos, pero revelan cuán profundo llega el compromiso de “controlar el flujo, no solo el acceso” cuando lo que está en juego es la seguridad nacional.

Por qué MAC no conquistó el mundo

Si MAC es estrictamente más fuerte que DAC, ¿por qué el modelo principal de tu portátil sigue siendo discrecional? Porque la garantía sin usabilidad no sobrevive al contacto con el trabajo real. La rigidez que bloquea el caballo de Troya también bloquea al analista que legítimamente necesita mover un gráfico de una presentación clasificada a un informe no clasificado — y cada punto de fricción así es presión para debilitar, sortear o deshabilitar la política. La historia premió a los modelos que la gente de hecho mantendría activados. Por eso precisamente el MAC moderno se volvió dirigido: en lugar de clasificar todo, SELinux y AppArmor confinan un puñado de servicios de alto riesgo (servidores web, contenedores) y dejan el resto del sistema con DAC ordinario. Obtienes la mayor parte del beneficio de contención por una fracción del costo de etiquetado — un compromiso pragmático que hizo al control obligatorio finalmente desplegable a escala.

Canales encubiertos: el límite de las etiquetas

Incluso una política de etiquetas perfectamente aplicada tiene una debilidad residual que vale la pena conocer: el canal encubierto. Bell-LaPadula impide que un proceso alto escriba abajo un archivo — pero dos procesos coludidos aún pueden filtrar información mediante efectos secundarios que las reglas de etiquetas no gobiernan. Un proceso alto puede variar su uso de CPU o llenar un disco en un patrón que un proceso bajo observa, señalando bits sin jamás “escribir” nada clasificado. Estos canales de temporización y de almacenamiento son lentos y difíciles de explotar, pero en los entornos de máxima garantía deben analizarse y mitigarse. La conclusión es aleccionadora y útil: las etiquetas controlan los flujos de información nombrados, no todos los físicos, así que MAC eleva la barrera enormemente sin alcanzar jamás un absoluto matemático.

Fortalezas y debilidades, con honestidad

Fortalezas. MAC ofrece un genuino control de flujo de información — la única cosa que DAC no puede hacer — así que resiste los ataques del caballo de Troya y del diputado confundido estructuralmente, no por vigilancia. Su política es central y consistente: la organización, no cada dueño, enuncia las reglas, así que “ningún dato Secreto llega jamás a un canal No clasificado” es aplicable como invariante. Es resistente a la manipulación por diseño — los usuarios comunes, incluidos los dueños, no pueden debilitarla. Y como capa de contención es soberbia: un proceso comprometido queda encajonado en exactamente sus necesidades etiquetadas.

Debilidades. Esa misma rigidez es el costo. Todo debe etiquetarse, correctamente, y mantener las etiquetas precisas a medida que los datos se crean y transforman es genuinamente difícil. La política central debe anticipar cada flujo de trabajo legítimo, y cuando no lo hace, los usuarios chocan con muros sin válvula de escape discrecional — que es por lo que el MAC sin gestión se deshabilita. Es administrativamente pesado, una habilidad especializada. Tiende a la sobre-clasificación (ante la duda, etiquétalo más alto), que luego frena la colaboración. Y ningún sistema MAC elimina por completo los canales encubiertos. MAC compra garantía y paga en flexibilidad y esfuerzo.

Un ejemplo trabajado: la carpeta de investigación, revisitada

Vuelve a la carpeta /research/roadmap de Sara del artículo de DAC, pero ahora imagina que la organización corre MAC con el roadmap clasificado Confidencial y Daniel habilitado solo como Interno. Sara todavía puede fijar permisos discrecionales — 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 archivo, encuentra que Interno no domina Confidencial, y lo deniega sin importar ninguna ACL que Sara añadiera. Y cuando el servicial troyano de Daniel intenta copiar el archivo a un recurso Interno, “no escribir abajo” lo bloquea: un proceso Confidencial no puede escribir en un objeto Interno.

La mismísima fuga que DAC no pudo impedir es ahora estructuralmente imposible — no porque Sara fuera cuidadosa, sino porque la política del sistema hace ilegal ese flujo de información. Esa es toda la propuesta de valor de MAC en un escenario. Fíjate, además, en lo que costó: alguien tuvo que clasificar el roadmap, habilitar a Daniel y mantener ambas etiquetas. Nadie obtiene esa garantía gratis, que es por lo que MAC se despliega donde lo que está en juego justifica el sobrecosto y se complementa con modelos más ligeros en todas partes.

Y fíjate en lo que MAC todavía no resuelve. Detuvo la fuga, pero no dijo nada sobre por qué Daniel debería o no ver el roadmap en términos de su trabajo. Su habilitación trata de confianza y sensibilidad, no del hecho de que trabaja en soporte y el roadmap pertenece a producto. Codificar “el acceso sigue lo que es tu trabajo” — limpiamente, a la escala de miles de empleados — es un problema distinto de controlar el flujo de información, y es para el que se construyó el siguiente modelo. MAC trazó la línea dura; RBAC organizará todo lo que hay dentro de ella.

Dónde encaja MAC entre los modelos

En el mapa del artículo de DAC, MAC es la respuesta al flujo de información no controlado. Se sitúa como un piso obligatorio bajo los modelos más flexibles: DAC maneja la compartición guiada por el dueño, RBAC (siguiente artículo) maneja el acceso basado en el trabajo a escala empresarial, ABAC maneja el contexto — y MAC, donde esté presente, los anula a todos con reglas de etiqueta no negociables. Una solicitud en un sistema plenamente en capas debe satisfacer la política MAC, los permisos DAC, la comprobación de rol RBAC y cualquier regla ABAC; cualquier capa puede denegar.

MAC es también el ancestro conceptual de ideas que conocerás más adelante. Su “política central que el dueño no puede anular” es la semilla del control de acceso basado en políticas y de las políticas como código; su pensamiento de flujo de información subyace a la prevención de pérdida de datos y a los programas de clasificación de datos modernos. Cuando un proveedor de nube etiqueta datos como “sensibles” y les bloquea salir de una región, eso es pensamiento MAC aplicado a la nube. El vocabulario cambió; la idea — etiquetas más una política de flujo obligatoria e impuesta por el sistema — no.

Los descendientes modernos de MAC: DLP, clasificación de datos y la nube

Puede que nunca configures una retícula Bell-LaPadula, pero casi con seguridad trabajas dentro de sus descendientes. Los programas de clasificación de datos — los niveles “Público / Interno / Confidencial / Restringido” que la mayoría de las empresas ahora corren — son etiquetas MAC con otro nombre, y la herramienta que estampa una etiqueta de sensibilidad en un documento y luego se niega a dejarlo enviar por correo externamente está haciendo cumplir una regla de no-escribir-abajo en espíritu. La Prevención de Pérdida de Datos (DLP) es la reencarnación comercial del control de flujo de información: inspecciona el contenido, asigna o lee una clasificación, y bloquea los flujos que moverían datos sensibles a un canal no autorizado — precisamente la preocupación que BLP formalizó, aplicada al correo, las subidas y las memorias USB en lugar de a redes clasificadas.

La nube revivió estas ideas a escala. Cuando etiquetas un bucket de almacenamiento o un dataset como “sensible” y una política le bloquea salir de una región o hacerse público, eso es control de flujo obligatorio, impuesto por el sistema y guiado por etiquetas — pensamiento MAC vistiendo vocabulario de nube. Las etiquetas de sensibilidad de Microsoft Purview, las etiquetas de recursos de AWS conectadas a políticas de control de servicio, y los VPC Service Controls de Google expresan todos “estos datos no pueden fluir ahí, sin importar quién lo pida”, que es la idea del piso obligatorio exactamente. Incluso la computación confidencial — mantener los datos cifrados y aislados incluso del operador del host — es el instinto de etiquetar-y-hacer-cumplir empujado al hardware.

Ver este linaje es prácticamente útil: significa que la teoría de los años setenta no es trivia sino el modelo mental detrás de controles que configuras hoy. Cuando una regla DLP te frustra bloqueando un envío legítimo, ahora sabes que es 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 degradación controlado y auditado, no deshabilitar la regla. El vocabulario de MAC te da el lenguaje para razonar sobre controles modernos de protección de datos que de otro modo parecen fricción corporativa arbitraria.

Recap

El Control de Acceso Obligatorio es el modelo que elimina la discreción para ganar garantía:

1. Decide el sistema, no el dueño. Una política central basada en etiquetas gobierna el acceso; ningún usuario común, ni siquiera un dueño, puede anularla. Eso es lo que significa “obligatorio”.
2. Las etiquetas combinan nivel y compartimento. Habilitaciones y clasificaciones forman una retícula de (nivel, compartimentos), haciendo cumplir tanto la sensibilidad como la necesidad de saber; el acceso requiere que la etiqueta del sujeto domine la del objeto.
3. Las reglas de flujo son el núcleo. Bell-LaPadula (no leer arriba, no escribir abajo) protege la confidencialidad y cierra la brecha del caballo de Troya; Biba la refleja para la integridad (no leer abajo, no escribir arriba).
4. Corre en todas partes, silenciosamente. El type enforcement de SELinux, AppArmor, el Control de Integridad Obligatorio de Windows y los sandboxes de iOS/Android son todos MAC superpuesto a permisos discrecionales.
5. La garantía cuesta flexibilidad. El etiquetado, el mantenimiento de la política y la rigidez son cargas reales — así que MAC es un piso no negociable para datos de alto riesgo, complementado por modelos más ligeros, no un reemplazo universal.

Tres preguntas para ponerte a prueba

1. Explica, usando específicamente la regla de “no escribir abajo”, por qué Bell-LaPadula detiene la mismísima fuga del caballo de Troya que DAC permite. ¿Qué tendría que ser cierto sobre el nivel del objetivo del atacante para que la fuga tuviera éxito bajo BLP?
2. Un compañero dice “usamos SELinux, así que hacemos seguridad militar multinivel”. Corrige la confusión: ¿qué hace cumplir en realidad el type enforcement de SELinux, y en qué se diferencia de los niveles de clasificación de Bell-LaPadula?
3. Tu organización quiere a la vez evitar que los secretos se filtren y evitar que una entrada no confiable corrompa datos críticos. ¿Qué modelo maneja cada preocupación, y por qué hacer cumplir ambas a la vez puede crear requisitos de etiqueta en conflicto para el mismo sujeto?

Ejercicios prácticos

1. Observa a MAC denegar algo que DAC permitió. En un sistema con SELinux (una VM o contenedor Fedora/RHEL), pon SELinux en modo enforcing, luego intenta hacer que un servicio lea un archivo fuera de su tipo permitido (por ejemplo, mueve contenido web a una ruta que no sea httpd_content_t y recarga). Observa la denegación en el registro de auditoría aunque los permisos DAC sean correctos, luego usa audit2allow para leer qué política haría falta.
2. Encuentra los niveles de integridad en 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 confirma que el navegador corre más bajo. En móvil, lee los entitlements/permisos declarados de una app. Mapea lo que encuentres de vuelta al “no escribir arriba” de Biba.
3. Diseña un esquema de dos niveles de etiqueta. Para un conjunto de datos pequeño que conozcas (digamos, registros de RRHH vs. anuncios públicos), define dos clasificaciones y dos habilitaciones, luego escribe las reglas de lectura/escritura de Bell-LaPadula para un sujeto en cada nivel. Identifica un flujo de trabajo legítimo que tus reglas bloquearían, y describe la excepción controlada que un sistema MLS real necesitaría para permitirlo.