Un proceso que se ejecuta como root tiene un acceso más amplio a varias llamadas del sistema, lo que aumenta el área de la superficie de ataque. Incluso si SELinux se aplica correctamente, aún habrá un mayor riesgo de explotación del núcleo. El motivo de esto es que muchas llamadas al sistema tienen comprobaciones para garantizar que el proceso se ejecuta como root (más específicamente, las comprobaciones suelen ser de CAP_SYS_ADMIN ). Si el proceso carece de esos permisos, rápidamente devuelve EPERM o un error similar. Si tiene esos permisos, entonces un error entre la verificación rápida de permisos y las verificaciones más recientes de LSM puede permitir que un proceso explote el kernel y desactive SELinux, o más.
Un proceso privilegiado puede ser capaz de realizar acciones que SELinux no puede restringir debido a que no hay un LSM hooks , en los que dependen los controles de acceso obligatorios. Estos ganchos están dispersos por todo el kernel y, cada vez que se alcanzan, verifican si el LSM ha restringido la acción o no. Por ejemplo, después de las comprobaciones de DAC (permisos estándar de Unix), existe un enlace LSM que verifica si se permite o no el acceso a un objeto del sistema de archivos determinado. Debido a que el kernel es tan complejo y tiene una relación tan extensa con el espacio de usuario, no es posible restringirlo todo. Para un ejemplo, la arriesgada llamada al sistema ioctl (un syscall catch-all contra descriptores de archivos que permite a los controladores del kernel registrar lo que está en efecto en sus propias llamadas al sistema) no está restringida por SELinux. Con el fin de proporcionar restricciones más precisas, deberá incluir en la lista blanca las llamadas individuales y sus argumentos. Esto se puede hacer utilizando el seccomp syscall filter.
No importa qué tan estricta sea su política de SELinux, siempre hay espacio para mejorar. Por ejemplo, ¿restringe el proceso ' límites de recursos ? Los procesos raíz pueden anular los límites de recursos, lo que puede tener implicaciones de seguridad (por ejemplo, es posible deshabilitar ASLR para procesos recién ejecutados si puede controlar los límites de recursos de la pila).
En general, hay cuatro riesgos principales en los que puedo pensar al ejecutar un proceso como root:
-
Como se explicó anteriormente, el área de superficie de ataque aumentada puede ser explotable.
-
La falta de defensa en profundidad significará que un error en SELinux podría conducir a la explotación.
-
SELinux no puede enganchar todas las acciones posibles que puede realizar un proceso raíz.
-
No importa qué tan estricta sea la política, siempre se puede mejorar (por ejemplo, ¿restringe los límites de tiempo?)
A menos que sea prohibitivamente difícil ejecutar el demonio como su propio usuario, sugeriría que elimine los privilegios de forma adecuada como si no estuviera utilizando ningún sistema de control de acceso.