$ chsh seguridad de comando con Set-UID

1

¿Por qué $ chsh tiene que ser un comando Set-UID? ¿Cuáles son las vulnerabilidades de un usuario normal que cambia su propio shell de tal vez bash a zsh?

Cualquier ayuda sería muy apreciada!

    
pregunta gabece 08.10.2015 - 07:57
fuente

2 respuestas

3

chsh es setuid porque para cambiar el shell de un usuario, debe modificar el archivo /etc/passwd de solo-root.

El administrador del sistema puede desear limitar los shells que un usuario puede elegir, por ejemplo, si a los usuarios se les asigna un shell que registra todos los comandos en syslog. La forma tradicional de hacer esto sería eliminar todos los demás shells del archivo /etc/shells , ya que chsh restringe a los usuarios a elegir shells en ese archivo. (Eso implica que para cualquier usuario que no esté restringido de esa manera, un administrador debe cambiar sus shells manualmente (edición /etc/passwd ), ya que ya no pueden usar chsh para hacerlo).

    
respondido por el gowenfawr 08.10.2015 - 14:39
fuente
1

No existe ninguna vulnerabilidad para que un usuario normal cambie su shell.

Sin embargo, el shell de un usuario se almacena en la base de datos del usuario, junto con otros campos confidenciales. La mayoría de las variantes de Unix almacenan la base de datos de usuarios locales en un solo archivo, /etc/passwd . (El nombre proviene del hecho de que el Unix original almacenó las contraseñas de los usuarios en ese archivo; en los sistemas modernos, las contraseñas ya no se almacenan en /etc/passwd , que se puede leer en todo el mundo, pero en un archivo que no se puede leer en todo el mundo , como /etc/shadow en Solaris y Linux.) Aunque permitir que un usuario normal cambie su shell no es un problema de seguridad, algunos otros campos son confidenciales (por ejemplo, el ID de usuario), pero en su mayoría, el archivo contiene información sobre todos los usuarios , por lo que permitir a un usuario modificarlo sería desastroso, ya que podrían cambiar la cuenta de cualquier otra persona.

Por lo tanto, los usuarios solo pueden modificar /etc/passwd indirectamente, a través de comandos como chsh y chfn .

Además, sería una vulnerabilidad permitir que los usuarios restringidos cambien sus shells. Se puede restringir una cuenta para ejecutar un comando específico configurando ese comando específico nada como su shell (o incluso, o efectivamente se puede evitar que se inicie sesión al configurar /sbin/nologin o /bin/false - o /bin/true para esa materia - como el shell ). Si el usuario pudiera de alguna manera cambiar su shell de inicio de sesión, evadiría la restricción de la cuenta. La restricción se implementa en chsh rechazando cambiar el shell si el shell actual del usuario no está en una lista blanca de shells "generalistas" permitidos almacenados en /etc/shells .

Además, el comando chsh se niega a cambiar el shell de un usuario a un shell que no se encuentra en esta lista blanca. Esto garantiza que los usuarios no se bloqueen a sí mismos de su cuenta al establecer una shell incorrecta allí, lo cual no es un problema de seguridad, sino un problema de soporte.

Para resumir, chsh debe tener privilegios elevados porque necesita modificar un archivo compartido entre todos los usuarios. Esto permite que chsh aplique políticas útiles adicionales.

Si bien sería posible dividir el shell en un archivo separado por usuario, eso requeriría un diseño más complejo con un archivo separado por cuenta. Unix se basaba en diseños simples, con información almacenada en un archivo de texto plano. El control de acceso detallado con un dato por archivo no es tradicional, tendría un impacto en el rendimiento (aunque no es grande en la actualidad) y las ventajas en términos de seguridad (no requieren que chsh y chfn tengan privilegios elevados) son bastante pequeñas Así que no hay ninguna razón convincente para cambiar este diseño.

Aunque sería posible y relativamente simple hacer que /etc/passwd sea propiedad de una cuenta del sistema dedicada (o mejor dicho, un grupo), y hacer que chsh setuid (o mejor, setgid) para esa cuenta dedicada, no lo haría Realmente ser un beneficio de seguridad. Si logras explotar chsh , no importa lo que puedas hacer con chsh en sí mismo, es casi seguro que podrás permitirte el acceso a la cuenta raíz.

    
respondido por el Gilles 08.10.2015 - 20:57
fuente

Lea otras preguntas en las etiquetas