Sí, definitivamente sería bastante malo. Solo estoy buscando argumentos más pesados sobre por qué el diseño de systemd es así (de seguridad).
Este es un seguimiento de un pregunta interesante sobre U & L . La pregunta explica que al cerrar la sesión del usuario systemd está esperando (el valor predeterminado, configurable) 90 segundos para que un disco esté disponible, el usuario sabe que el disco no está allí y desea omitir esa espera. Sostengo que la única opción es configurar systemd para usar un retraso más corto. Esto se debe a que permitir que un usuario sin privilegios dé instrucciones (digamos a través de una señal de interrupción) a systemd sería un problema.
Por ejemplo: un usuario sin privilegios que puede enviar señales a systemd podría esperar a que un administrador reinicie SELinux y provoque una falla durante su inicio. Ese es el ejemplo que obtuve de la parte superior de mi cabeza.
Ahora, supongamos que alguien escribe un contenedor para el cierre de sesión del usuario que se ejecutará en setuid , esto se hará para una "fácil de usar" de systemd (por ejemplo, enviar una interrupción que inhabilitará el tiempo de espera antes de un SIGKILL se envía a un proceso que no finalizó con SIGTERM). Esto no es particularmente difícil de escribir, simplemente puede crear un script y agregarlo a la configuración del administrador de pantalla ( lighdm tiene session-cleanup-script= , gdm tiene PostSession scripts, o incluso un simple .bash_logout para sin cabeza máquinas). La envoltura permitirá una comunicación con la interfaz SIGNAL de systemd , que se encuentra en man systemd en la sección SIGNALS .
Para enfocar la pregunta, veamos la escalada de privilegios. es decir, si tenemos un atacante que logró obtener acceso a una cuenta de usuario sin privilegios y ahora podemos dar comandos a systemd a través de ese contenedor, ¿cómo podría escalar privilegios a una cuenta root ?