Run code you do not trust in a safe sandbox
Sometimes you have to run the thing you are unsure about: a script from a stranger, a macro in a file a client sent, a proof-of-concept from a security advisory. This mission builds a throwaway, sealed box to run it in, a Docker container with no network, a read-only filesystem, no Linux superpowers, hard caps on processes and memory, and a non-root user, so that even if the code is hostile it cannot reach your real files, your network, or your system. You prove each wall holds by running a small, harmless probe inside that tries to break out and fails at every turn. It pairs with Analyse a file without running it (which covers looking before you leap): this is the one for when you have to leap.
- Docker, on Windows, macOS or Linux. The Build a hacking lab lesson installs Docker Desktop and explains containers, images and networks from scratch; this mission assumes you can already run
dockercommands - A Linux-style terminal to run everything from. On Windows that means WSL2 (the slim Linux built into Windows), because the resource limits in this mission rely on the Linux kernel's cgroup support that WSL2 provides. On Linux or a Mac your normal terminal is that place
- About 150MB of free disk space for the small sandbox image (83MB) and room to work
- Optional but recommended: the companion lesson Analyse a file without running it, which covers inspecting a suspect file safely before you ever decide to run it. Sandboxing is what you reach for when inspection is not enough and you must actually run the thing
When to sandbox, and the idea behind it
Understand what a sandbox is and when it is the right tool, before you build one, so you use it deliberately rather than as a false comfort.
A sandbox is a sealed, disposable place to run a program so that whatever the program does stays inside and cannot touch anything that matters. Isolation is the property that makes it a sandbox: a strong boundary between the code and your real files, your network and your system, so that a hostile program is trapped behind walls instead of running loose on your machine.
You reach for a sandbox when you have decided you must actually run something you do not fully trust. A script someone sent you. A build tool from a repository you have not read line by line. A macro inside a document. A proof-of-concept attached to a security advisory that you want to see work. The companion lesson, Analyse a file without running it, covers the first and safer move, which is to inspect a thing without executing it at all. This mission is for the cases where looking is not enough and you have to press go. Running it inside a sandbox means that if the thing turns out to be malicious, the blast radius is a throwaway box you delete, not your laptop.
The tool here is a container, a lightweight sealed box that holds a program and its dependencies and runs it apart from the rest of your computer, managed by Docker. The important honesty up front is this: a container shares your computer's single Linux kernel (the core of the operating system) with every other container and with the host. A virtual machine (VM) is heavier and slower to start but runs its own separate kernel, so the wall between it and your real system is thicker. A container is a strong, fast, convenient box. A VM is a stronger, slower one. Step 6 covers when the difference matters and what to use instead. For most suspect scripts, a locked-down container is the right balance, and it is what you build here.
One idea runs through the whole build: take away everything the code does not need. No network, because a script that only has to process a file has no reason to talk to the internet. No ability to write to disk, because it has no reason to change your system. No special powers, no spare processes, no spare memory, and no running as the all-powerful user. Each thing you remove is one less thing a hostile program can use.
CarefulA sandbox reduces risk, it does not make running unknown code safe in an absolute sense. A container shares the host kernel, and kernel flaws that let code escape a container do exist and are found from time to time. Treat the sandbox as a strong wall for ordinary malicious scripts, not as a guarantee against a determined, specialised attacker. For genuinely dangerous samples, use a throwaway virtual machine or an isolated analysis environment, as step 6 explains.TipEverything in this mission runs against code and files you choose to put in the box, on your own machine. That is the lawful and sensible way to use it: a sandbox is for examining things you have a right to examine, on hardware you own.