Para responder a su pregunta, es importante comprender qué es SELinux, cómo se implementa y cómo afecta la seguridad del sistema.
Lo primero que hay que entender es que SELinux se implementa utilizando el Marco del Módulo de Seguridad de Linux (LSM). El marco LSM hasta hace muy poco se ha utilizado para proporcionar restricciones adicionales en el sistema por encima de lo que ya se proporciona a través del sistema de control de acceso discrecional (DAC). El sistema DAC son sus ACL, UID / GID y bits de permiso. La idea detrás de LSM es que era necesario proporcionar restricciones de acceso más allá de lo que está representado en DAC. Entonces, la premisa número 1 es que los LSM solo pueden / deberían restringir aún más los permisos y, a menos que algo esté mal con la ubicación del gancho en el núcleo, ese debería ser el caso.
La razón por la cual es así es por la forma en que se realizan las comprobaciones de acceso en el núcleo. Para que se otorgue cualquier permiso, debe pasar inicialmente la verificación de control de acceso DAC. A menudo, las personas se quejan de los problemas de SELinux y, sin embargo, no ven las denegaciones de AVC porque, para empezar, ni siquiera están pasando la verificación DAC. Esto significa que SELinux nunca debería otorgarle la capacidad de hacer algo que su usuario no pueda hacer. SELinux solo debe tomar lo que su usuario está autorizado a hacer y restringirlo aún más. SELinux no utiliza la autorización del usuario para determinar el acceso a los recursos. Basa sus decisiones en etiquetas de seguridad asignadas a procesos y recursos en el sistema y luego las compara con un conjunto de reglas en la política de seguridad. Si observa el código del kernel, verá que la verificación de datos se realiza primero, seguida de una llamada a una función security_ *. Las funciones security_ * son la api para el marco LSM y, bajo el capó, cada módulo implementa sus propias versiones de los ganchos.
- ¿Cómo abordan los investigadores de seguridad las recompensas de errores?
- ¿Cómo puede un antivirus derrotar a sitios web y software maliciosos?
- ¿Es posible hacer un virus informático que elimine otros virus?
- ¿Por qué se debe cambiar una contraseña regularmente?
- ¿Cuál es la mejor solución para una actualización congelada de Windows?
Ahora, esto no quiere decir que no haya habido errores que no hayan violado este principio. Aquí hay dos ejemplos de ellos. En la historia del desarrollo de SELinux que conozco (y he estado involucrado durante más de 7 años en este punto) solo ha habido dos errores que han causado un problema. El primero nunca llegó a ser un núcleo liberado, pero se comprometió en un núcleo de desarrollo fue una comparación de euid contra uid 0. Se suponía que era una comparación de equivalencia y era un error tipográfico de una asignación (== vs =). Esto hizo que, cuando se realizó el control, convirtiera euid en uid 0 en lugar de compararlo. Fue encontrado y corregido antes de que se lanzara el núcleo con el error. El segundo error estaba en la lógica de cómo manejamos mmap_minaddr. Debido a la forma en que se establecieron las verificaciones en el código, la verificación de SELinux anuló la configuración del núcleo si se otorgaron ciertos permisos de SELinux. El error aquí fue que SELinux violó el propósito de los LSM. El marco LSM solo está ahí para restringir aún más los permisos, no para otorgarlos. Esto fue una violación de este director. Que yo sepa, estos son los únicos dos errores en SELinux que han resultado en un privilegio.
Por eso, desde una perspectiva de diseño, está bien. Sin embargo, desde la perspectiva del código, ha habido cientos de personas que han estado involucradas en el código SELinux a través de su desarrollo y mantenimiento.
Editar
