Sandboxing

A sandbox gives untrusted code a deliberately small world: limited files, memory, CPU, processes, syscalls, devices, and network access. If the code crashes, loops forever, or tries to read a secret, the boundary should contain the damage. Chrome's Site Isolation is the version a billion people use without noticing: every site gets its own renderer process that cannot read the filesystem directly. Code runners reach further, using gVisor or Firecracker microVMs for a stronger boundary than an ordinary process.

Use one for uploaded document conversion, user-written code, plugins, build jobs from untrusted pull requests, and risky parsers. Start with nothing allowed, then grant a temporary working directory, exact input files, bounded resources, and only the network destinations the task requires. Destroy the environment after each job.

A default container is not a security boundary. A container shares the host kernel, may run as root, and often keeps outbound internet access, mounted credentials, and the cloud metadata endpoint. Layer isolation with a non-root user, syscall filtering, resource limits, an empty credential set, blocked egress, and a patched runtime. Sandbox escapes exist, so the host must still assume the guest is hostile.