← Back to list

Sandboxing-The Security Fence You Never Knew Was There

In one of my recent lectures my professor introduced a concept that genuinely made me think differently about how software security works…

Vaishnavi Kolape · 2026-05-04 09:01 · 3 claps · 2.9 min read
#sandboxing #cybersecurity #seccomp #chroot #linux
Open on Medium ↗
Wiki topics: 🔒 · Cybersecurity 🔓 · Open Source 🥊 · Combat Sports

Sandboxing-The Security Fence You Never Knew Was There

In one of my recent lectures my professor introduced a concept that genuinely made me think differently about how software security works. It wasn’t a flashy topic. No hacking tools, no exploits. Just a simple question — what do you do when you can’t trust the code you’re running?

The answer is sandboxing.

What Is a Sandbox?

A sandbox is exactly what it sounds like. Just like a child’s sandbox — you can play inside it, make a mess, do whatever you want — but you can’t leave it and affect anything outside.

In computing it means running untrusted or potentially dangerous code in a restricted environment where even if something goes wrong it can’t damage the rest of the system.

My professor put it simply — you have bad code written in C and C++, often taking input from hostile users. You can’t always rewrite it. So instead you put it in a box.

The Old Way — chroot Jail

Before modern sandboxing existed people used something called chroot. It works by changing what a process thinks is the root of the filesystem. Basically tricking it into thinking a small subfolder is the entire computer. It can’t read or write anything outside that folder.

Sounds good in theory. But it had serious problems. It only restricted file access — the process could still make network connections, call the kernel directly and if it had root privileges it could actually escape the jail entirely.

It was a good first attempt. But not enough.

The Modern Way — seccomp

This is where it gets interesting. My lecture introduced seccomp — a Linux feature that takes sandboxing much further.

Every program communicates with the operating system through system calls — requests like “open this file”, “send data over the network”, “create a new process”. There are hundreds of them.

seccomp lets you say — this process is only allowed to make these specific system calls. Everything else is blocked completely.

So even if an attacker fully compromises the sandboxed program they’re stuck. The program literally cannot do anything dangerous because those system calls don’t exist for it anymore.

What surprised me in the lecture was how widely this is actually used. Tools I use every day rely on seccomp — Docker, Chrome, Android, OpenSSH. It’s quietly running in the background keeping things contained.

The Broker and Target Model

My professor also introduced a model I found really clever. Modern sandboxes split things into two parts:

The Target — the untrusted code that runs with almost no permissions. It can exist and execute but can’t do anything sensitive directly.

The Broker — the trusted manager. Any time the target needs something sensitive — a file, a network connection, anything — it has to ask the broker. The broker decides yes or no.

Think of it like a prisoner and a guard. The prisoner can exist in the cell. But for anything beyond that they have to ask permission.

Sandboxing

Sandboxing

Why Not Just Use a VM?

This came up in my lecture too and it’s worth clarifying. Virtual machines and emulation tools like Wine or WSL are not sandboxes. They weren’t designed for security isolation.

Treating a VM as a security boundary just because code is running inside it is a mistake. VMs can be escaped. Emulation layers have their own vulnerabilities. Security in these environments comes from additional layers like seccomp — not the VM itself.

Defence in depth. Never rely on one layer alone.

Why This Matters

My professor made a point that stuck with me — sandboxing exists because rewriting bad legacy code is expensive. It’s cheaper to put a fence around it than to fix it.

That might sound like a shortcut but it’s actually a smart security principle. You accept that code will be imperfect, that attackers will find ways in, and you design systems assuming that. Sandboxing is that assumption built into the architecture.

Every container escape, every browser exploit, every mobile malware story you’ll read involves someone finding a gap in one of these layers. Knowing how they’re built is how you start to understand how they break.

Follow along for more !!!


메타데이터
post_id
729b5a76dbd7
slug
sandboxing-the-security-fence-you-never-knew-was-there-729b5a76dbd7
url
https://medium.com/@vaishnavikolape/sandboxing-the-security-fence-you-never-knew-was-there-729b5a76dbd7
canonical_url
https://medium.com/@vaishnavikolape/sandboxing-the-security-fence-you-never-knew-was-there-729b5a76dbd7
author_url
https://medium.com/@vaishnavikolape
status
ok
fetched_at
2026-07-10 20:52:23