Je voudrais installer un certain script bash appelé 42FileChecker en utilisant les commandes:

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

Mais je ne sais pas si 42FileChecker.sh fera des choses étranges sur mon PC car je suis un débutant et je ne sais pas ce qui se passe dans ce script. Existe-t-il un moyen de l'exécuter dans un terminal factice ou un dossier racine factice ou quelque chose comme ça pour voir ce qui se passe afin que j'évite quelque chose de fou comme le formatage de mes disques. J'aimerais également savoir comment tester les shells pour les futurs scripts de shell, même si 42FileChecker.sh est sûr.

Je ne suis pas un expert dans ce domaine, mais je recommanderais d'utiliser straceet docker.

Donc, créez d'abord un conteneur Docker selon les instructions de cette réponse . Mais l'ajout étant que strace vous dira quels appels système sont effectués. Ou pour citer:

strace est un utilitaire d'espace de diagnostic, de débogage et pédagogique pour Linux. Il est utilisé pour surveiller et falsifier les interactions entre les processus et le noyau Linux, qui incluent les appels système, les livraisons de signaux et les changements d'état des processus.

Vous pouvez combiner ces commandes pour

docker exec -it ubuntu_container strace bash ./42FileChecker.sh

Si vous n'êtes pas sûr de ce que fait un script, il vaut mieux ne pas l'exécuter tant que vous n'êtes pas sûr de ce qu'il fait. Les moyens de réduire le rayon de dégâts d'un mauvais script incluent son exécution avec un nouvel utilisateur, son exécution dans un conteneur ou son exécution sur une machine virtuelle. Mais cette première affirmation est toujours valable: si vous n'êtes pas sûr de ce que fait quelque chose, pensez à ne pas l'exécuter avant de le faire.

Comme l'a dit @ctt, c'est probablement une bonne idée de l'exécuter d'abord dans un bac à sable. L'utilisation d'une machine virtuelle est probablement la solution la plus simple. Le multipass est assez simple.

Installez multipass (en supposant que vous ne l'avez pas déjà fait):

sudo snap install multipass --beta --classic

Faites tourner une nouvelle machine virtuelle:

multipass launch --name myvm

Connectez-vous à votre nouvelle VM:

multipass shell myvm

Exécutez ensuite votre script (dans votre VM):

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

Comme l'école que vous fréquentez a publié les scripts, le meilleur endroit pour exprimer vos préoccupations est avec vos instructeurs.

Cela dit, nous pouvons vous aider à déchiffrer le code ligne par ligne. Il est probablement impossible pour quiconque ici d'analyser tout le code.

Vous avez en fait 40 scripts bash avec un total de 5 360 lignes. Je les ai combinés ensemble et j'ai cherché des commandes bash / shell qui pourraient être utilisées abusivement. Ils semblent tous être utilisés normalement :

$ 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

$ 

• Il n'y a aucune rm -rf /commande pour effacer toute la partition du disque dur.
• Il n'y a aucune exigence sudoà utiliser pour exécuter le script.
• Le script s'assure que seules les Cfonctions autorisées sont utilisées dans les fichiers vérifiés.
• Une navigation rapide du code bash / shell montre qu'il est rédigé par des professionnels et facile à suivre.
• L'utilisation de shellcheck sur les fichiers inclus fusionnés ne révèle que trois erreurs de syntaxe.
• Les noms des auteurs sont identifiés et l'auteur principal a même sa photo sur sa githubpage.
• Bien qu'il n'y ait aucune garantie dans la vie, il 42FileCheckersemble sûr à utiliser.

Ce ne sont pas des scripts bash lisibles par l'homme dont vous devez vous inquiéter autant. Ce sont des objets binaires compilés que vous ne pouvez pas lire qui sont préoccupants. Par exemple, un programme appelé "shiny-bouncy-sphere" pourrait peindre quelque chose comme ça sur votre écran, mais en arrière-plan, il pourrait effacer tous vos fichiers.

Réponse originale

Il est préférable de demander à l'auteur du script ce qu'il fait. En effet, vous pouvez presque poster votre question textuellement comme elle apparaît ci-dessus.

Demandez également à l'auteur:

• Quels fichiers sont mis à jour?
• Que se passe-t-il en cas de panne due à une panne de courant ou à un bug du programme?
• Une mini-sauvegarde peut-elle être effectuée en premier?

Et toutes les autres bonnes questions auxquelles vous pouvez penser.

Edit 1 - Inquiétudes à propos d'un auteur malveillant.

Vous ne devez utiliser un logiciel qu'avec de nombreuses bonnes critiques publiques. Alternativement, les auteurs auxquels vous faites confiance ici dans Ask Ubuntu comme Serge, Jacob, Colin King, etc. D'autres sites respectés comme Ask Ubuntu et leurs membres respectés devraient également être considérés comme "non malveillants".

L'avantage des "auteurs respectés" ici dans Ask Ubuntu est qu'ils jettent leur estime de soi sur des "points de réputation". S'ils devaient écrire intentionnellement du code qui "volait" ou "endommageait" des données, ils perdraient rapidement leur réputation. En effet, les auteurs pourraient subir la «colère des mods» et être suspendus et / ou se voir retirer 10 000 points de réputation.

Edit 2 - Ne suivez pas toutes les instructions

J'ai approfondi les instructions de votre script bash:

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

La méthode "sûre" consiste à exécuter uniquement la première ligne:

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

Cela télécharge les scripts mais ne les exécute pas. Utilisez ensuite nautilus(gestionnaire de fichiers) pour inspecter les répertoires et fichiers installés. Très vite vous découvrez qu'il existe une collection de scripts bash écrits par un groupe d'étudiants en France.

Le but des scripts est de compiler et de tester des programmes C pour les fonctions incorrectes et les fuites de mémoire.

Vous pouvez utiliser Docker. Les conteneurs Docker sont isolés du système d'exploitation hôte, de sorte que toute activité malveillante restera dans un conteneur, tant que vous ne le laissez pas spécifiquement en redirigeant des ports ou en montant des systèmes de fichiers.

Pour installer docker:

sudo apt-get install docker.io

Pour télécharger un nouveau conteneur Ubuntu Bionic:

docker pull ubuntu:bionic

Après cela, connectez-vous au conteneur

docker run -it ubuntu:bionic

et effectuer l'opération douteuse en elle:

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

Envisagez d'utiliser le mode de débogage en exécutant le script en tant que:

$ bash -x scriptname

Autres informations utiles sur Bash

Le mode de débogage n'empêchera pas le script de faire quelque chose de mal, mais il vous permettra de parcourir le script ligne par ligne et d'examiner les effets. Vous pouvez également vérifier le script pour certaines erreurs et / ou exploits potentiels courants, par exemple rechercher les scripts pour toute occurrence de rmet regarder ces commandes de très près. Un grand nombre de ces outils ont une aide intégré pour les essayer, par exemple rm ne supprimera pas un répertoire par défaut, il a besoin de la -r, -Rou --recursivepossibilité de le faire.

Il peut même y avoir des outils de type antivirus qui rechercheraient un script bash pour ces modèles, mais je n'en connais pas de nom. Vos exemples de scripts sont en quelque sorte extra sifflants, dans le sens où ils téléchargent d'autres outils, donc chacun d'entre eux doit également être examiné. Il peut également être utile de vérifier quels serveurs ils contactent.

Les informations pertinentes pour fournir une réponse ne se trouvent malheureusement que dans un de vos commentaires:

J'apprends le C dans le cours Ecole 42. Les fonctions que je crée doivent passer par cette vérification de norme. J'ai besoin d'installer le 42FileChecker dans Ubuntu pour exécuter cette vérification de norme.

La situation est donc qu'en pratique, vous avez la possibilité de sauter le cours, ou vous pouvez exécuter le script pour effectuer des vérifications normatives sur vos sources. Parler avec votre instructeur n'est guère une option, en raison du manque de la première (ce ne serait pas une option sinon de toute façon, aucune école ne changera sa procédure parce qu'un élève n'est pas satisfait).
La question de savoir quoi faire pour limiter les dommages possibles de ce script ne se pose donc même pas. Ce n'est pas un script aléatoire qu'une fille excitée aux gros seins vous a envoyé par e-mail et que vous devez exécuter pour voir sa photo .
Vous faites un cours de programmation. Cetteest l'endroit où ce script est entré en jeu. La question est de savoir si vous souhaitez ou non respecter les conditions du cadre pour réussir le cours.

Cependant, si vous êtes vraiment inquiet, il y a toujours la possibilité d'exécuter le script dans un conteneur ou une machine virtuelle, et de placer vos sources dans un dossier partagé, ou sur un partage réseau exposé par le conteneur / la machine virtuelle. C'est à peu près le chemin de la paranoïa complète, mais là encore, la virtualisation n'est pas vraiment compliquée de nos jours, donc cela ne coûte pas cher.

Sauf la possibilité improbable qu'un exploit vraiment dur soit contenu dans ce script, la connexion en tant qu'utilisateur non root (que vous n'avez guère le choix de faire autrement sur Ubuntu) et éviter de taper sudo sans raison évidente empêche à peu près 99% des toutes les mauvaises choses qui pourraient arriver de toute façon. Tels que le formatage du disque dur, qui vous inquiète. Un utilisateur normal ne peut tout simplement pas faire cela. La pire chose qui puisse arriver est que le script efface le répertoire personnel de l'utilisateur. Alors quoi, pas de problème, vraiment.