Antes de discutir la protección de recursos del 
kernel en Off
conviene explicitar que hablamos de la protección de recursos
físicos. Los recursos lógicos del SO (ficheros, procesos, etc.)
implementados ahora por las aplicaciones pueden emplear el modelo de
protección que se desee.
Se han empleado diversos mecanismos para suministrar protección en los SSOO existentes en la actualidad. Podríamos agruparlos en tres grandes familias:
Su principal ventaja es que no requieren de una gestión centralizada y poseen un buen nivel de transparencia. Esto las hace convenientes para SSOO distribuidos. Su principal desventaja es la dificultad en la revocación de permisos y la necesidad de almacenar al menos una por cada cliente con derecho a utilizar el recurso afectado.
La desventaja fundamental es la ineficiencia que resulta de la evaluación (la cual involucra up-calls en algunos sistemas). La ventaja es la flexibilidad, ya que permiten implementar capabilities y ACLs de forma selectiva.
El esquema de protección empleado por un DAMN debería permitir la
implementación de cualquier sistema de protección en el nivel
de aplicación, manteniendo dentro del kernel sólo aquello indispensable
para implementar otros mecanismos de protección en área de usuario. El
sistema de protección empleado debe así mismo ser utilizable en una
red, no sólo dentro de un nodo. También hay que reseñar que hablamos
de protección de recursos físicos, el esquema de protección empleado
para recursos lógicos puede ser radicalmente diferente. Este enfoque
consistente en la protección de recursos físicos y la delegación de la
protección de recursos lógicos a las aplicaciones resulta útil cuando
se desean obtener sistemas altamente seguros, como se dice en
[117]
En Off utilizamos un esquema intermedio entre capabilities y guardas que hemos denominado guardabilities (ver figura 2.4). Para cada unidad asignada de un recurso dado, Off mantiene una guardability que (dependiendo del valor que tenga) puede comportarse como una guarda o cómo una capability. La guardability está asociada al recurso que protege.
Una guardability es un objeto capaz de almacenar alguno de los siguientes valores:
empleados por el kernel sólo se emplean cuando el
kernel instala traducciones hacia ellos. Una vez instaladas éstas, no
volvemos a realizar operaciones sobre dichos marcos (aunque
naturalmente sí que empleamos la memoria de éstos). Estos marcos
debieran tener su protección a DENY.
El primer y el segundo caso permiten implementar eficientemente todas aquellas situaciones en las que los accesos se conceden o deniegan globalmente: recursos de dominio público --tales como las listas de asignación de recursos que mantiene el kernel-- y recursos utilizados sólo una vez --como los marcos de página empleados por el kernel en el ejemplo anterior.
El tercer y cuarto caso permiten el empleo de guardas (y por tanto, ACLs) y capabilities allí donde se considere conveniente.
Hay dos elementos que conviene explicar, uno es el concepto de propietario de un recurso. Este concepto se utiliza cuando un recurso tiene una guardability con valor GUARD. Para Off, cada unidad de recurso del sistema asignada tiene un propietario identificado por un portal. Debemos mencionar en este punto que la implementación de esta abstracción ``propietario'' es tarea del SO o de las aplicaciones que ejecutan sobre Off. En Off no hay ``procesos'' ni otras abstracciones que puedan considerarse como ``propietarios'' de los recursos asignados. Off tan sólo necesita un punto de acceso (un portal) al que enviar las excepciones y notificaciones relacionadas con la unidad de recurso de que se trate.
El segundo elemento es el empleo de una referencia a memoria de usuario para almacenar la tira de bits que permite validar un acceso. El mantenimiento de esta tira en área de usuario permite una revocación rápida de recursos y el empleo de métodos eficientes en espacio para almacenarlas (por ejemplo, el empleo de una única tira de bits para más de una unidad de recurso). Evidentemente, cuando dicha memoria es remota puede producirse un trasiego de páginas entre distintos nodos, así que es conveniente que las aplicaciones mantengan compactadas todas sus guardabilities.
Los derechos de acceso suministrados por los clientes en sus peticiones no identifican a ningún recurso del mismo modo que los identificadores no se emplean como mecanismo de protección en Off.
Para optimizar todos aquellos casos en los que determinadas operaciones están siempre prohibidas Off almacena una máscara de bits junto con cada guardability. Cada bit corresponde a una posible operación sobre la unidad de recurso a la que protege. Si el bit asociado a una operación es cero, dicha operación se prohibe y cualquier acceso que la invoque será inmediatamente rechazado.
La separación entre identificadores, o nombres, y derechos de acceso
hace más simple la implementación y permite que las aplicaciones tomen
el relevo al kernel en la protección del sistema (el kernel sólo
necesita identificadores para manipular recursos, el modelo de
protección puede pues alterarse sin modificar el kernel). Creemos que
el modelo de protección debería estar implementado en el nivel de
aplicación, eliminando la responsabilidad del kernel tanto como sea
posible. Haciendo que el sistema utilice nombres al margen del
mecanismo de protección empleado abrimos la posibilidad de
experimentación con distintos modelos de protección a nivel de
aplicación.
Creemos que el modelo de protección adoptado en Off es tanto simple como potente y, en cualquier caso, cualquier otro modelo puede incorporarse en el futuro mediante la adaptación del sistema.
