Los módulos de seguridad de Linux ( LSM ) son un marco que permite que el kernel de Linux admita sin sesgos una variedad de modelos de seguridad informática . LSM tiene licencia bajo los términos de la Licencia Pública General GNU y es una parte estándar del kernel de Linux desde Linux 2.6. AppArmor , SELinux , Smack y TOMOYO Linux son los módulos de seguridad aprobados actualmente en el kernel oficial.
Diseño
LSM fue diseñado para responder a todos los requisitos para implementar con éxito un módulo de control de acceso obligatorio , al tiempo que impone la menor cantidad de cambios posibles al kernel de Linux. LSM evita el enfoque de interposición de llamadas del sistema utilizado por Systrace porque no escala a núcleos multiprocesador y está sujeto a ataques TOCTTOU (carrera). En cambio, LSM inserta " ganchos " (llamadas ascendentes al módulo) en cada punto del kernel donde una llamada al sistema a nivel de usuario está a punto de resultar con un acceso a un objeto interno importante del kernel como inodos y bloques de control de tareas.
LSM tiene un alcance limitado para resolver el problema del control de acceso , sin imponer un parche de cambio grande y complejo en el núcleo principal. No se pretende que sea una "General gancho " o " upcall " mecanismo, ni tampoco apoya de funcionamiento de virtualización a nivel de sistema .
El objetivo de control de acceso de LSM está muy relacionado con el problema de la auditoría del sistema , pero es sutilmente diferente. La auditoría requiere que se registre cada intento de acceso. LSM no puede entregar esto, porque requeriría muchos más ganchos, para detectar casos donde el kernel " cortocircuita " llamadas al sistema fallidas y devuelve un código de error antes de acercarse a objetos importantes.
El diseño de LSM se describe en el artículo Módulos de seguridad de Linux: Soporte de seguridad general para el kernel de Linux [1] presentado en USENIX Security 2002. [2] En la misma conferencia se presentó el artículo Uso de CQUAL para el análisis estático de la colocación de ganchos de autorización [3] que estudió el análisis estático automático del código del kernel para verificar que todos los ganchos necesarios se hayan insertado realmente en el kernel de Linux.
Adopción
Historia
En la Linux Kernel Summit de 2001, la NSA propuso que SELinux se incluyera en Linux 2.5. [5] Linus Torvalds rechazó SELinux en ese momento, porque observó que hay muchos proyectos de seguridad diferentes en desarrollo, y dado que todos difieren, la comunidad de seguridad aún no ha formado un consenso sobre el modelo de seguridad definitivo. En cambio, Linus encargó a la comunidad de seguridad que "lo convirtiera en un módulo".
En respuesta, Crispin Cowan propuso [6] LSM: una interfaz para el kernel de Linux que proporciona suficientes "ganchos" (upcalls) desde dentro del kernel de Linux a un módulo cargable para permitir que el módulo aplique controles de acceso obligatorios. El desarrollo de LSM durante los dos años siguientes estuvo a cargo de la comunidad de LSM, incluidas contribuciones sustanciales de Immunix Corporation , NSA , McAfee , IBM , Silicon Graphics y muchos colaboradores independientes. LSM fue finalmente aceptado en la corriente principal del kernel de Linux y se incluyó como parte estándar de Linux 2.6 en diciembre de 2003.
En 2006, algunos desarrolladores de kernel observaron que SELinux era el único módulo LSM ampliamente utilizado incluido en el árbol de fuentes del kernel de Linux convencional. Si solo debe haber un módulo LSM ampliamente utilizado, se razonó, entonces la dirección indirecta de LSM es innecesaria, y LSM debe eliminarse y reemplazarse con el propio SELinux. Sin embargo, hay otros módulos LSM mantenidos fuera del árbol del kernel principal ( AppArmor , Linux Intrusion Detection System , FireFlier , CIPSO , Multi ADM , etc.), por lo que este argumento condujo a dos resultados: 1. que los desarrolladores de estos módulos comenzaron a poner esfuerzo en incorporar sus respectivos módulos, y 2. en la Cumbre de Kernel de 2006 , Linus afirmó una vez más que LSM se quedaría porque no quiere arbitrar cuál es el mejor modelo de seguridad.
Es probable que LSM permanezca ya que los módulos de seguridad adicionales Smack (versión 2.6.25), TOMOYO Linux (versión 2.6.30, junio de 2009) y AppArmor (versión 2.6.36) fueron aceptados en el kernel principal.
Recepción
A algunos desarrolladores del kernel de Linux no les gusta LSM por varias razones. LSM se esfuerza por imponer la menor sobrecarga posible, especialmente en el caso de que no se cargue ningún módulo, pero este costo no es cero, y algunos desarrolladores de Linux se oponen a ese costo. LSM está diseñado para proporcionar solo control de acceso, pero en realidad no impide que las personas usen LSM por otras razones, por lo que a algunos desarrolladores del kernel de Linux no les gusta que se pueda "abusar" de él para otros fines, especialmente si el propósito es omita la licencia GPL del kernel de Linux con un módulo propietario para ampliar la funcionalidad del kernel de Linux.
A algunos desarrolladores de seguridad tampoco les gusta LSM. Al autor de grsecurity no le gusta LSM [7] por su historial, y porque LSM exporta todos sus símbolos facilita la inserción de módulos maliciosos ( rootkits ) así como módulos de seguridad. Al autor de RSBAC no le gusta LSM [8] porque está incompleto con respecto a las necesidades de RSBAC. En particular, el autor de RSBAC argumenta que: "LSM solo se trata de un control de acceso adicional y restrictivo. Sin embargo, el sistema RSBAC proporciona muchas funciones adicionales, por ejemplo, redirección de enlaces simbólicos, secure_delete, deshabilitación parcial de DAC de Linux. Todo esto tiene que ser parcheado en las funciones del kernel en un parche separado ". El proyecto Dazuko argumentó [9] que apuntar a la API de LSM es un objetivo en movimiento, ya que cambia con cada lanzamiento del kernel, lo que lleva a un trabajo de mantenimiento adicional. A otros desarrolladores les gustaría tener módulos LSM apilados, por ejemplo, el desarrollador de Yama LSM. [10]
Referencias
- ^ "Módulos de seguridad de Linux: soporte de seguridad general para el kernel de Linux" . 2002 . Consultado el 3 de febrero de 2007 .
- ^ "XI Simposio de Seguridad de USENIX" . 2002 . Consultado el 3 de febrero de 2007 .
- ^ "Uso de CQUAL para el análisis estático de la colocación del gancho de autorización" . 2002 . Consultado el 3 de febrero de 2007 .
- ^ Landlock: control de acceso sin privilegios
- ^ Stephen Smalley, Timothy Fraser, Chris Vance. "Módulos de seguridad de Linux: ganchos de seguridad general para Linux" . Consultado el 26 de octubre de 2015 .Mantenimiento de CS1: utiliza el parámetro de autores ( enlace )
- ^ Crispin Cowan (11 de abril de 2001). "Interfaz del módulo de seguridad de Linux" . lista de correo de linux-kernel . Consultado el 3 de febrero de 2007 .
- ^ "grsecurity" . grseguridad . Consultado el 3 de febrero de 2007 .
- ^ "RSBAC y LSM" . RSBAC . Consultado el 3 de febrero de 2007 .
- ^ "dazuko" . dazuko . Consultado el 26 de diciembre de 2017 .
- ^ Edge, Jake (23 de junio de 2010). "Apilamiento LSM (de nuevo)" . www.lwn.net . Consultado el 28 de mayo de 2015 .
enlaces externos
- "Código fuente y estadísticas del proyecto" . Archivado desde el original el 7 de marzo de 2005 . Consultado el 8 de febrero de 2006 .
- Artículo de la revista SysAdmin sobre niveles de seguridad BSD
- Proyectos de seguridad basados en el kernel de Linux