Compensaciones de seguridad del MAC basado en nombre de ruta (por ejemplo, TOMOYO, grsecurity, AppArmor, ...)

  

Con bastante frecuencia, este enfoque se considera inseguro, ya que indica que un archivo puede tener varios nombres al mismo tiempo (enlaces, montaje de enlaces, etc.).

Es ciertamente cierto que un archivo podría tener múltiples contextos de seguridad, uno para cada nombre. Sin embargo, si esto es inseguro o no, depende de cómo lo veas:

• Esta función de AppArmor no requiere que los sistemas de archivos remotos sean compatibles con AppArmor, por lo que, por ejemplo, se puede implementar para rutas NFS.
• Por lo general, Unix DAC permanece habilitado, por lo que incluso las aplicaciones interesantes como el contenido de /usr/bin no deberían poder escribirse. En teoría!
• Puede haber controles adicionales para evitar que los usuarios finales se monten o vinculen.

Sin embargo, aparte de eso, el objetivo de los proyectos de tipo MAC es limitar los procesos y los usuarios, de modo que un proceso que se ejecuta como usuario solo se ejecuta con los permisos necesarios que necesita. Pocas aplicaciones, excepto quizás ln , necesitan la capacidad de crear enlaces simbólicos y las que no las requieren en todos los directorios y rutas. Por lo tanto, debería ser posible implementar la contención deseada para la mayoría de los procesos.

Si bien no sufre el problema potencial de las rutas de acceso, la seguridad basada en inodos tiene sus problemas:

• La información adjunta a la seguridad del archivo se almacena en xattrs (atributos extendidos), lo que significa consideraciones especiales para sistemas de archivos de red .
• Algunas aplicaciones cambian valores de inodo que puede causar problemas al trabajar con contextos de seguridad; específicamente, es probable que su archivo vuelva a la seguridad predeterminada contexto si lo editas y vim funciona de esta manera.

Creo que la diferencia es bastante sutil y no es un caso de uno es más seguro que el otro, ya que cada uno tiene sus ventajas e inconvenientes. Comprendidos correctamente, ambos permiten la implementación de políticas seguras.

Grsecurity no es un sistema de MAC basado únicamente en nombres de ruta como TOMOYO o AppArmor. La política se describe utilizando rutas de acceso (igual que cualquier otro sistema, incluido SELinux), pero estas se convierten en pares de inodo / desarrollo en el momento de la activación y se utilizan posteriormente. Los nombres de ruta solo se usan cuando se combinan expresiones regulares de la política o para proporcionar "recreación de políticas"; dado el caso en el otro comentario aquí, SELinux revierte un archivo modificado por vim al contexto de seguridad predeterminado (¡un problema grave!), Grsecurity detecte este caso y aplique la política anterior sobre ese objeto al nuevo.

Curiosamente, mientras se agrupa en grsecurity con sistemas de MAC basados en nombres de ruta puros y se difunde FUD, SELinux ha agregado recientemente el uso de información de nombres de archivo en versiones recientes para hacer exactamente lo que ha estado haciendo grsecurity desde el día 1.

Parece cierto lo que dijo Schopenhauer: "Toda la verdad pasa por tres etapas. Primero, es ridiculizada. Segundo, es violentamente opuesta. En tercer lugar, se acepta como autoevidente".

Analizo más detalles sobre este tema en mi presentación del tutorial de RBAC de grsecurity: enlace

-Brad

Creo que el control de acceso basado en el nombre de ruta en general no tiene fallas conceptuales en absoluto, incluso puede tener ventajas, pero las implementaciones actuales no son convenientes.

Ventaja es que puede tener una política más clara y más comprensible especificada en un solo lugar, y no tiene complicaciones de que xattrs se extienda por todo el sistema de archivos. Pensabilidad, digo, lo cual es importante. Desventaja es que algunas implementaciones no pueden manejar la vinculación o el cambio de nombre de manera fácil para los usuarios .

Hay respuestas de los autores de TOMOYO: enlace Básicamente, dicen que puedes prohibir vincular / cambiar el nombre de los archivos importantes, y eso por defecto está prohibido el enlace / cambio de nombre, así que "no hay problemas". No estoy de acuerdo, todo lo que complica la creación y el mantenimiento de políticas. Sin embargo, depende de los objetivos que tengas.