Lisex 0.0 es un prototipo orientado a expertos en el área de seguridad en sistemas operativos; particularmente no está destinado al usuario promedio. Implementa las mejoras de seguridad sólo en el sistema de archivos. Lisex 0.0 se desarrolló sobre el núcleo de Linux 2.4.14. La idea es que Lisex 0.0 sea usado como prueba de concepto. No incluye ningún paquete de software para red ni seguridad a nivel de red debido a que se espera que sea utilizado como sistema stand-alone.

A pesar de ser un prototipo, Lisex 0.0 posee muchas de las propiedades de la versión final a desarrollar: el modelo de seguridad ha sido especificado y verificado formalmente, en parte se utilizó testing funcional basado en el modelo, la implementación incluye un modelo MLS y características DAC extendidas, etc. Por otro lado, en tanto prototipo, ciertas características han sido programadas de forma ineficiente, incompleta o inconveniente.

Manual del usuario y del administrador

Manual de referencia para el prog

En principio Lisex 0.0 es completamente compatible con Linux en general. Más precisamente, Lisex 0.0 agrega algunas llamadas al sistema que no es necesario que sean utilizadas por otros componentes, y aquellas llamadas que han sido modificadas (por ejemplo, open, creat, etc.) preservan su prototipo, es decir esperan los mismos parámetros y retornan los mismos valores que las originales.

La compatibilidad se rompe si se entiende por esta que el sistema debe comportarse de forma idéntica al original en aquellas situaciones previstas por el software original. En otras palabras, en Lisex 0.0 se ha modificado el comportamiento de algunas llamadas de forma tal que si son invocadas en una situación prevista en Linux, la respuesta puede ser notablemente distinta. Por ejemplo, root no necesariamente podrá abrir cualquier archivo pues en open se han implementado controles que consideran a root como cualquier otro usuario.

Algunos de estos cambios semánticos son decisiones de diseño que podrían modificarse (de hecho esto se hará en futuras versiones) pero otros implementan la esencia misma de los modelos MLS.

Las características de seguridad de Lisex 0.0 son las siguientes (la mayoría están descriptas en el Manual del usuario y del administrador y otras en la Introducción a la seguridad de Lisex 0.0):

	ACL asociada a cada archivo y directorio que pueden incluir usuarios y grupos. Cada ACL posee una lista de propietarios del archivo o directorio en lugar de un único propietario
	Modificación de la semántica del "grupo" other en el modo de archivos y directorios. Se lo considera como el grupo All definido en MS NT, es decir no representa al resto de los usuarios sino a todos.
	Se alteró la estructura del nodo-i de ext2 y VFS.
	Se modificaron algunas operaciones de nodo-i a nivel de ext2 y VFS.
	Grupo root equivalente al usuario root.
	Cuenta y "grupo" secadm a cargo de la administración de los atributos MAC de cuentas de usuarios, archivos y directorios
	Se agregaron clases de acceso asociadas a archivos y directorios.
	Se agregaron clases de acceso asociadas a usuarios y procesos.
	Modificación de la semántica de las siguientes llamadas al sistema:

	chdir exige permiso de lectura sobre el directorio en lugar de permiso de ejecución.
	chmod y chown no se pueden ejecutar sobre archivos abiertos y mantienen consistencia con la ACL.
	create crea un archivo asociándole la clase de acceso del proceso que la solicita y realiza verificaciones MLS como si el directorio padre estuviera abierto para lectura y escritura.
	execve considera la ejecución de un programa como la apertura de un archivo en modo read por lo que efectúa controles MLS.
	mkdir crea un directorio asociándole la clase de acceso del proceso que la solicita y realiza verificaciones MLS como si el directorio padre estuviera abierto para lectura y escritura.
	open incorpora control de acceso MLS y DAC extendido sobre todos los archivos abiertos por cada proceso incluido el ejecutable mismo y las librerías utilizadas.
	rmdir realiza verificaciones MLS como si el directorio padre estuviera abierto para escritura.
	setuid cambia la identidad del proceso sólo si se verifican las propiedades de seguridad simple y DAC extendido.
	stat retorna la información tradicional, pero la obtiene de la ACL.
	unlink realiza verificaciones MLS como si el directorio padre estuviera abierto para escritura.

	aclstat retorna la información contenida en la ACL de un archivo o directorio.
	acladd agrega a la ACL de un archivo o directorio, usuarios o grupos como lectores, escritores o dueños.
	chobjsc cambia la clase de acceso de un archivo o directorio, sólo puede ser ejecutada por miembros del "grupo" secadm.
	chsubsc cambia la clase de acceso de un usuario, sólo puede ser ejecutada por miembros del "grupo" secadm.
	acldel elimina de la ACL de un archivo o directorio, usuarios o grupos.
	oscstat retorna la clase de acceso de un archivo o directorio.
	ownerclose permite que un dueño de un archivo abierto lo cierre aun cuando lo tiene abierto otro usuario.
	sscstat retorna la clase de acceso de un usuario

	Se modificó la forma en que trabaja el programa login en cuanto a la entrega de terminales.
	Se removió del sistema de archivos la implementación de capacidades (capabilities) presente en el núcleo 2.4.14.
	Se modificó el programa debugfs de forma tal que permita editar el sistema de archivos de Lisex 0.0.
	Se modificó la semántica del permiso de ejecución (x) en archivos y directorios.

Características implementadas de forma ineficiente o inadecuada

Implementa las mejoras de seguridad sólo en el sistema de archivos, lo que permite que cierto tipo de caballo de Troya pueda seguir actuando. No se efectuó un testing completo del sistema; sólo se generaron los casos de prueba a nivel de la especificación y se ejecutaron sólo algunos de ellos a nivel de la implementación. Las ACL son de longitud fija, configurable en tiempo de compilación del núcleo. El conjunto de categorías de las clases de acceso es de longitud fíja, configurable en tiempo de compilación del núcleo. Las categorías están implementadas cada una como un entero (de 32 bits) cuando podrían implementarse 32 categorías con un único entero. No se implementaron etiquetas legibles por el usuario para las categorías o niveles utilizados por el sistema (human readable labels). Las clases de acceso de los usuarios deben modificarse o añadirse re-compilando el núcleo del sistema y se cargan cada vez que el sistema se inicializa; concretamente están atornilladas en el código de la función main del núcleo. No se programaron comandos para modificar las clases de acceso de usuarios. Los programas para listar clases de acceso o ACL son muy rudimentarios. La clase de acceso de root debe ser máxima en el orden definido sobre el conjunto de clases de acceso con el único fin de poder entregar las terminales en el momento de login; esto sin dudas es una brecha de seguridad que será eliminada en futuras versiones. root puede invocar a setuid para convertirse en cualquier oficial MAC. Esto es una brecha de seguridad importante debido a que cualquier caballo de Troya instalado (inadvertidamente) por los administradores podrá alterar clases de acceso.

Muchas de estas características serán re-implementadas en la futura versión: GIDIS Trusted Linux.