Limitaciones de la inspección de la pila

Este es un seguimiento de ¿Cómo funciona la Inspección de pila? que explora la noción con más detalle

La inspección de la pila es un mecanismo para garantizar la seguridad en el contexto de las máquinas virtuales JVM y CLR cuando los módulos de código descargados externamente de diferentes niveles de confianza se pueden ejecutar juntos. Las bibliotecas del sistema necesitan alguna forma de distinguir entre las llamadas que se originan en código no confiable y las llamadas que se originan en la aplicación de confianza. Esto se realiza asociando con el código el principal correspondiente a su origen. Luego, los permisos de acceso se registran en la pila y cada vez que se realiza una llamada a un método del sistema sensible, la pila se recorre para ver si los permisos apropiados para el principal que realiza la llamada están presentes en la pila.

¿Cuáles son las limitaciones de la inspección de la pila? ¿Qué mecanismos se han propuesto para reemplazarlo? ¿Se han realizado cambios significativos en el modelo desde que se introdujo a finales de los 90?

La inspección de la pila es necesaria porque los programas en JVM y CLR tienen acceso predeterminado a operaciones peligrosas, por lo que se debe hacer algo para evitar desastres. Por ejemplo, un programa no confiable puede hacer referencia a una biblioteca de E / S y llamarla:

using IO;
...
IO.DeleteFile("/home/foo/bla");

Entonces, en cada operación peligrosa realizada, debemos verificar si está permitida. Con la inspección de la pila, generalmente es complicado entender quién tiene acceso a qué. También dificulta las optimizaciones, como las llamadas en línea y de cola.

Un mecanismo superior es no dar a cada programa acceso automático a operaciones peligrosas en primer lugar. En este modelo no hay forma de importar una biblioteca IO. La única forma de obtener acceso a una biblioteca de E / S es si alguien más te lo dio. Esto se llama capacidad de seguridad. Una introducción se puede encontrar aquí .

En cambio, escribiríamos el programa anterior así:

Main(IOLibrary IO){
  IO.DeleteFile("/home/foo/bla");
}

La biblioteca IO es un parámetro para el punto de entrada del programa, y ​​esto se llama capacidad (porque le da cierta capacidad, en este caso para hacer IO). Para poder ejecutar este programa, debemos tener acceso a una capacidad de E / S nosotros mismos y ejecutar el programa llamando Main(ourIOlibrary). Si estamos ejecutando un programa no confiable, simplemente no le pasamos nuestra biblioteca de E / S, ya que podría usar esa biblioteca para eliminar nuestros archivos. En algunos casos, queremos dar a un programa no confiable acceso limitado al sistema de archivos. En ese caso, creamos un contenedor alrededor de nuestra propia biblioteca de E / S que solo permite el acceso a un determinado directorio, y lo pasamos al programa no confiable en lugar de a la biblioteca de E / S completa.

Entonces, si necesitamos una capacidad de E / S para invocar un programa que necesita una capacidad de E / S, eso también significa que cualquier cosa que se invoque nuestro programa debe tener acceso a una capacidad de E / S para poder dárnosla. Entonces, ¿de dónde viene su capacidad de IO? Bueno, eventualmente hay un punto donde el humano que opera la computadora invoca un programa. Este humano tiene acceso a todas las capacidades del sistema, por lo que pudo transmitir la capacidad de E / S. Si este humano no confía en el programa que está ejecutando, simplemente no pasará su capacidad de E / S.

Probablemente pueda imaginar fácilmente otros tipos de capacidades: acceso a internet, acceso para dibujar cosas en su pantalla, etc. Por ejemplo, un sistema de complementos de navegador seguro podría dar una capacidad gráfica a un complemento no confiable que solo le permite pintar gráficos en un rectángulo predefinido en la pagina.

Una limitación de la inspección de la pila como se implementa tradicionalmente es que rompe las llamadas de cola adecuadas. En particular, las implementaciones típicas necesitan mantener todo el "stack" en todo momento. Clements y Felleisen muestran cómo se puede remediar este problema utilizando una técnica llamada "marcas de continuación" en su artículo Una semántica recursiva de cola para inspecciones de pila en ESOP 2003.