Usos prácticos no gubernamentales de los modelos Biba, Bell-LaPadula, etc.

Tal vez no tanto como en las definiciones formales, pero el Control de acceso obligatorio más genérico, y los subconjuntos de no-escritura, etc., a veces se usan, en combinación con otros modelos, como parte de un esquema de autorizaciones más complejo , usualmente en aplicaciones empresariales personalizadas.

La necesidad de diferenciar los permisos según un modelo jerárquico estricto y / o de mantener el "estado" actual, ocurre en sistemas de negocios complejos, aunque no a menudo.

También señalaría que XACML también puede admitir esto (aunque sea un poco indirecto).

Las técnicas también se "usan" a veces en algunos ejercicios de análisis de riesgos (por ejemplo, rastreando posibles violaciones de flujo de datos de estas expectativas).

Además, como mencionó, se está implementando un formulario similar en los sistemas operativos actuales: Windows, y también SELinux como @ D.W. mencionado, así que sí, parece ser de aplicación general, y se está volviendo muy común.

En términos generales, esos modelos tienden a no usarse exactamente como están. El problema es que muy rápidamente "todo se vuelve bajo", porque todo depende (a través de una larga cadena de dependencias) de algo que tienes a través de Internet. Como resultado, tienes muchos falsos positivos o cuadros de diálogo molestos.

Sin embargo, hay sistemas ampliamente utilizados que se basan en parte en las ideas que se encuentran en esos modelos. Mencionaste Windows. Otro ejemplo es SELinux, que se implementa ampliamente en las máquinas de Fedora Linux. Un tercer ejemplo (más vagamente relacionado) es el seguimiento de la corrupción, que se utiliza para detectar vulnerabilidades y proteger los sistemas contra ataques controlados por datos. El seguimiento de la contaminación es conceptualmente para el modelo Biba: los datos no contaminados son "altos", los datos contaminados son "bajos" y todo lo que depende de los datos contaminados ("bajos") también se etiqueta como contaminados ("bajos").

Entonces, mientras que los modelos han demostrado ser inviables en su forma original (para la computación de propósito general), las variantes menos restrictivas han tenido algún impacto.

En una vida anterior, mi empresa tenía clientes que no confiaban entre sí y quería tener laboratorios privados para cada cliente y cajas más negras en sus líneas de comunicaciones.

Por otro lado, nosotros queríamos transferir nuestro software a las máquinas de laboratorio desde nuestra red y recuperar algunas cosas, como los archivos de control modificados para las herramientas. Los archivos de control eran efectivamente un lenguaje de alto nivel, por lo que queríamos mantener todos los laboratorios actualizados con las versiones más recientes.

Mi jefe por lo tanto me envió a un curso de Solaris de confianza de una semana, y para simplificar en exceso el plan se convirtió en mantener las herramientas en UNCLAS y los datos de los clientes en diferentes categorías en RESTRICTED.

Más tarde nos dimos cuenta de que solo necesitábamos categorías, una para cada cliente y otra para nosotros.

No hicimos mucho con el esquema, pero ejecuté Trusted Solaris 7 en una máquina doméstica durante varios años, hasta que el disco de arranque comenzó a morir.

Creo que esto podría hacerse de manera más elegante y simple con SELinux (matraz), pero necesito leer más antes de comprometerme a que ese sea el caso ...

--dave