¿Es seguro dejar un shell raíz ejecutándose en una sesión de pantalla separada?

Tengo curiosidad acerca de la seguridad de dejar un shell raíz ejecutándose dentro de una sesión de pantalla separada. Normalmente nunca hago esto.

Además del potencial de que mi cuenta de usuario no root se vea comprometida (contraseña expuesta, clave ssh comprometida, etc.), ¿hay otros vectores de entrada en una sesión de pantalla separada y protegida por contraseña que debería preocuparme, o puede una pantalla separada? sesión se considera inerte?

Creo que es un problema de seguridad, porque "Aparte del potencial de que mi cuenta de usuario no root se vea comprometida" puede ser bastante grande.

Pero hay otros mayores riesgos más allá de eso. Por ejemplo, ahora te has abierto a un exploit teórico que te permite cambiar los permisos en el directorio de socket de pantalla ( /var/run/screenen mi sistema, pero a veces /tmpse usa). Ese exploit ahora tiene un camino para obtener root, que de otro modo no podría.

sudotiene otras ventajas, si puedes entrenarte para usarlo para cada comando en lugar de hacerlo sudo su -. Registra acciones (que, a menos que inicie sesión de forma remota, no aumenta significativamente la seguridad, pero le da un rastro de lo que ha hecho). Y ayuda a prevenir accidentes al requerir una escalada intencional para cada comando, en lugar de cambiar a una sesión completamente privilegiada.

Si tiene un shell raíz en una sesión de pantalla (separado o no, protegido por contraseña o no), y su screenejecutable no es setxid, entonces un atacante que obtenga sus privilegios puede ejecutar comandos en ese shell. Por lo menos, pueden hacerlo al seguir el proceso de la pantalla.

Si la pantalla es setuid o setgid, y la sesión está separada y protegida por contraseña, entonces, en principio, se necesita la contraseña de la pantalla para ejecutar comandos en ese shell. Si este principio se cumple, alguien que solo haya comprometido su cuenta tendría que poner un troyano en su lugar y esperar a que escriba la contraseña. Sin embargo, la superficie de ataque (es decir, el número de lugares donde las cosas pueden salir mal debido a un error o una configuración incorrecta) es incómodamente grande. Además de las características básicas de seguridad del sistema, confía en:

• pantalla para obtener la verificación de contraseña correcta.
• pantalla para evitar el acceso a la sesión por otros medios.
• pantalla para usar los mecanismos de control de acceso del sistema operativo correctamente (por ejemplo, permisos en las tuberías).
• el núcleo para realizar las comprobaciones de seguridad de ptrace correctamente (esta es una fuente frecuente de vulnerabilidades).
• el shell corriendo para no hacer nada estúpido.
• alguna otra característica para no morderte.

"Alguna otra característica para no morderte": sí, eso es vago. Pero siempre es una preocupación en seguridad. Puede que sienta la tentación de descartar esto como una simple ilusión, pero ¿realmente pensó en todo? Por ejemplo…

Siempre que pueda escribir en el dispositivo terminal, puede inyectar datos en la entrada de ese shell. Debajo de la configuración predeterminada de la pantalla en mi máquina:

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

Esto se inserta ␛]lfoobar␛len la secuencia de entrada del shell. \ekes la secuencia de control que permite que una aplicación (o cualquier cosa que pueda escribir en el dispositivo terminal) establezca el título de la ventana (consulte la sección "Nombrar ventanas" en el manual de la pantalla ), y \e[21thace que el terminal informe su título en la entrada estándar de la aplicación ( La pantalla no documenta esta secuencia, pero la implementa; puede encontrarla CSI Ps ; Ps ; Ps ; ten la lista de secuencias de control de xterm . De hecho, al menos en la pantalla 4.0.3, todos los caracteres de control se eliminan del título informado, por lo que el shell lee lfoobar(suponiendo ␛]que no esté vinculado a un comando de edición) y sin nueva línea. Por lo tanto, el atacante no puede ejecutar un comando de esa manera, pero puede rellenar un comando comochmod u+s /bin/sh seguido de muchos espacios y un aviso de aspecto probable.

Screen implementa varias otras secuencias de control de riesgo similares, no sé cuál es su potencial de vulnerabilidades. Pero con suerte ahora puede ver que la protección que ofrecen las contraseñas de sesión de pantalla no es tan buena. Una herramienta de seguridad dedicada como sudo es mucho menos probable que tenga vulnerabilidades.

El propietario solo puede acceder a las tuberías creadas por la pantalla, por lo que esto no debería ser un problema de seguridad.