Asegurando entornos de shell restringidos

Question

Asegurando entornos de shell restringidos

#1 de bstpierre (9 votos)

9

He leído algunas cosas para indicar que los shells restringidos se pueden romper si no se implementan correctamente (incluso wikipedia , por ejemplo).

Estoy buscando alguna guía sobre las causas de los agujeros de seguridad en los depósitos restringidos y cómo resolver estos problemas.

Supongo que el problema principal son los binarios que le permites al usuario usar; si alguno de estos programas facilita la ejecución de otros programas / scripts con privilegios más altos.
¿Eso significa que un shell rbash predeterminado es relativamente seguro?
¿Hay algún programa específico que sea (más o menos) definitivamente seguro / no seguro (hasta ahora he visto ejemplos específicos de vim y scp utilizados para romper)? ¿Y hay otras cosas en que pensar?

Además, ¿existen mejores alternativas al uso de un shell restringido cuando desea limitar los comandos que un usuario puede ejecutar?

Actualización 1
Después de lo que bstpierre mencionó con el uso de ssh command =, ¿alguien ha intentado usar command = para forzar al usuario a ejecutar un script que tomó información del usuario usando SSH_ORIGINAL_COMMAND y luego ejecutó comandos / programas adicionales limitados basados en esa entrada? Me imagino que esto tendría un caso de uso bastante limitado, pero me parece viable siempre y cuando el script sea cuidadoso con la información que aceptó.

Actualización 2
La sugerencia que hice en la Actualización 1 resulta ser exactamente lo que hace la gitolita; usando command = y SSH_ORIGINAL_COMMAND, con algo de magia mágica para diferenciar entre ramas. Información de sus docs .
Así que sé que este método es una alternativa viable, pero todavía estoy buscando una respuesta a la consulta original sobre shells restringidos.

linux

pregunta Demelziraptor 13.12.2011 - 18:36

fuente

1 respuesta

Lea otras preguntas en las etiquetas linux

¿Cómo afectará IPv6 a las técnicas de mitigación de DDoS? Comenzando con SmartCards; ¿Qué equipo necesito, qué necesito saber?

score 9 · Answer 1

He configurado entornos de shell restringidos que ponen al usuario en una jaula chroot. Solo los archivos ejecutables mínimos se copian en la cárcel. El usuario de la shell casi no tiene permisos en la cárcel: todo está predeterminado para denegar, y solo proporciono permisos cuando es necesario. Puedes combinar la cárcel con rbash para una capa adicional de protección. La ventaja de una jaula chroot es que, si el usuario sale de rbash, todavía está atrapado en una jaula chroot y no puede acceder al resto de su sistema. (Ha habido casos en los que ha sido posible escapar de una jaula chroot, pero está bien construido en un sistema operativo parchado que es difícil de atacar).

Otro punto a considerar es si realmente necesita proporcionar un shell. ¿Podría configurarse el servicio que necesita proporcionar como un servicio web simple y seguro?

Finalmente, si el shell se proporciona a través de ssh, puede restringir el conjunto de comandos disponible para el usuario al solicitar el inicio de sesión a través de las teclas y al establecer command= en su archivo authorized_keys. Sin embargo, debe tener cuidado aquí porque si los comandos que autoriza le permiten al usuario "salir", no está mejor que con el mismo ataque contra un shell restringido.