Los sistemas operativos comerciales implementan varias formas de control de acceso discrecional⁵ en las cuales los usuarios pueden definir la política de seguridad y/o asignar atributos de seguridad (por ejemplo, la información de control de acceso a los archivos propios). En general, los mecanismos DAC han probado ser útiles para definir políticas de seguridad flexibles. Sin embargo, estos mecanismos tienen una gran desventaja, sin importar la implementación específica de que se trate, pues son susceptibles, por su propia naturaleza, a ataques por medio de caballos de Troya⁶. El aspecto más insidioso de los caballos de Troya es que no requieren ni el descubrimiento ni el uso de una falla de seguridad en el sistema operativo. Un ataque exitoso de un caballo de Troya puede efectuarse utilizando únicamente las funciones más deseables y perfectamente documentadas de un sistema operativo absolutamente correcto. En general, una vez que un caballo de Troya es ejecutado, la función oculta del programa comienza a acceder toda la información a la que su ejecutante tiene derecho, filtra los datos que no son de interés y envía el resto a algún lugar accesible por el atacante. Tales acciones le son posibles debido a que, para el sistema operativo, es un proceso común y corriente accediendo archivos, abriendo conexiones, solicitando recursos, etc. a nombre de cierto usuario legítimo del sistema.

Además, si el caballo de Troya es cuidadosamente programado y distribuido no será considerado un virus. Como ejemplo basta el descripto más arriba. Tal herramienta no será detectada como un virus por ningún software anti-virus pues nadie la ha reportado como tal y es muy difícil que alguien lo haga pues el programa no causa ningún daño visible, ni intenta propagarse a otros sistemas o programas; únicamente envía información fuera del sitio (cosa que por otra parte se efectúa diariamente).

Dado que los caballos de Troya pueden inutilizar cualquier mecanismo DAC y que en la práctica es extremadamente costoso y difícil mantenerlos fuera de su sistema, creemos que la verdadera solución, para mantener niveles aceptables de confidencialidad, estriba en implementar alguna forma de control de acceso obligatorio (MAC) a nivel del sistema operativo. Una política de seguridad obligatoria es aquella política de seguridad en la cual la definición de la política y la asignación de atributos de seguridad están estrictamente controladas por los administradores. La implementación de un esquema de seguridad MAC altamente confiable, como la seguridad multi-nivel (MLS), es uno de los objetivos básicos del proyecto.

Con el crecimiento del comercio electrónico fue necesario crear gran confianza en la criptografía y en toda clase de trucos de seguridad, pero la verdad es que no podemos confiar datos críticos a estas herramientas tan útiles sin contar con una base de cómputo confiable. En otras palabras, no sólo debemos prestar atención a cómo la seguridad es implementada y alcanzada, sino que también debemos determinar si el diseño y la implementación son correctos. El proyecto GIDIS Trusted Linux tiene este objetivo en mente. Proponemos construir un S.O. seguro de alta calidad basado en la interfaz de UNIX (Linux) utilizando las técnicas y herramientas más avanzadas y rigurosas de la Ingeniería de Software, incluyendo métodos formales para la especificación, diseño y verificación.

Los sistemas operativos que soportan políticas de seguridad obligatorias no se han convertido en productos con buena presencia en el mercado comercial. Una de las razones principales es que tienden a ser escasamente usables respecto de sus primos DAC. La seguridad multi-nivel (MLS) es un esquema de seguridad MAC basado en el modelo de seguridad de Bell-LaPadula [7]. MLS es un modelo de seguridad extremadamente poderoso pero si no es implementado correctamente puede tornarse innecesariamente e intolerablemente restrictivo [14]. La experiencia ganada con Lisex nos posibilitó localizar la mayoría de los problemas de las implementaciones anteriores y proponemos varias soluciones ingeniosas contra aquellos. En consecuencia otro objetivo de este proyecto es evitar estos problemas y construir un software tan usable como seguro.

La concepción de un S.O. nuevo, usable y seguro brinda escasas ventajas si no es capaz de ejecutar las aplicaciones existentes. Precisamente, este es el caso de muchas implementaciones MLS pues exigen la re-codificación de la mayoría de las aplicaciones. Así, como último objetivo queremos agregar al núcleo de un sistema operativo las características de seguridad mencionadas, pero sin afectar la funcionalidad y el desempeño de las aplicaciones existentes. De esta forma, no será necesario re-codificar ninguna aplicación previamente desarrollada y por tanto la nueva versión tendrá una gran porción del mercado rápidamente disponible.