¿Cuáles son las diferencias prácticas entre el modo dirigido de SELinux y un sistema operativo basado en capacidades?

Creo que muchos de los problemas con los sistemas basados en capacidades y nuestra comprensión de ellos es que hay pocos en la naturaleza. Sin embargo, está de suerte: FreeBSD acaba de agregar Pimiento apoyo a su versión 9.0. Capsicum es un proyecto de investigación para implementar un [conjunto de capacidades prácticas livianas] [1]. Este trabajo involucró a personas del equipo de investigación de seguridad de Google e incluye una compilación de navegador de Chrome experimental diseñada para usar el sistema.

Lo que podría interesarte más es la lista de características:

  

• capacidades - descriptores de archivos refinados con derechos específicos
  

Prácticamente, operará como SELinux, con obvias diferencias de administración. Tiene analogías para escribir etiquetas.

  

• descriptores de proceso: reemplazo de ID de proceso centrado en la capacidad
  

Tiene analogías con los dominios SELinux. Desde la perspectiva del usuario, puede parecer que no es diferente.

Ahora, en el siguiente conjunto de características, verá por qué las capacidades aún no están en uso común:

  

• objetos de memoria compartida anónimos: una extensión de la API de memoria compartida POSIX para admitir objetos de intercambio anónimo asociados con descriptores de archivos (capacidades)
  
• rtld-elf-cap - vinculador de tiempo de ejecución ELF modificado para construir aplicaciones de espacio aislado
  
• libcapsicum: biblioteca para crear y usar capacidades y componentes de espacio aislado
  

Si bien SELinux requiere soporte de kernel y una política y está bien para ir a partir de ahí, dejando de lado los problemas de configuración, prácticamente la implementación de capacidades requiere un enfoque modificado de las API disponibles y la preparación posterior de las aplicaciones para acceder a ellas.

Ahora específicamente a sus preguntas:

  

¿Pueden ambos impedir el acceso al mismo nivel granular?

Aproximadamente comparable, sí. SELinux puede, por ejemplo, describir un dominio de aplicación y darle acceso a una carpeta determinada solo para lecturas. Los sistemas basados en la capacidad, al inicializar el proceso, simplemente no le otorgan la capacidad de escribir en esa ruta, o rechazar dichas solicitudes posteriormente. Es la forma en que se implementan lo que varía.

  

¿Son posibles diferentes ataques en SELinux en modo dirigido que en un sistema operativo basado en capacidades?

Honestamente, es bastante difícil de decir. No conozco ningún sistema operativo basado en capacidades de despliegue masivo que haya despertado el interés suficiente como para ser probado seriamente en la carretera. Sin embargo, espero que, en última instancia, el objetivo siga siendo el mismo: persuadir a un proceso para que ejecute el código utilizando sus privilegios (capacidades) más altos. Pueden variar para explotar la forma en que los desbordamientos de búfer varían de acuerdo con el programa al que se dirige, pero en última instancia, el objetivo fundamental sigue siendo el mismo.

Siempre puedes darle una oportunidad . También hay documentación sobre las modificaciones de la API de las que he hablado.

Exención de responsabilidad: No estoy afiliado de ninguna manera con el Proyecto Capsicum, la Universidad de Cambridge o el Proyecto FreeBSD.

Las capacidades son diferentes de los permisos, que es lo que SELinux llama capacidades (doh).

Como ejemplo, las capacidades se pueden transferir a otros programas, posiblemente atenuados. Esto contrasta con los modelos basados en ACL donde los controles de acceso se administran por separado de los programas.

Piense en las capacidades como referencias imperdonables a objetos, o posiblemente un subconjunto de los métodos en objetos, que un programa puede usar en tiempo de ejecución. Entonces, si quiero que alguien me actualice un informe, puedo pasarles una capacidad (referencia a la interfaz rw del archivo), que pueden proporcionar a un programa que actúe en su nombre. A su vez, pueden delegar el proceso de actualización a otra persona, pasando la capacidad. No tengo que abrir directorios para un acceso más amplio.

Esto conduce a un estilo de programación en el que las relaciones de seguridad / confianza se consideran en el momento del diseño y son una extensión bastante natural del caso de uso: por ejemplo, si entrego mi cámara a alguien para usar, también les doy permiso para utilízalo.