Sandboxing agents at the kernel level

I'm Abhinav. I work on agent infrastructure at Greptile - the AI code review agent. One of the things we do to ensure Greptile has full context of the codebase is let it navigate the filesystem using the terminal.

When you give an LLM-powered agent access to your filesystem to review or generate code, you're letting a process execute commands based on what a language model tells it to do. That process can read files, execute commands, and send results back to users. While this is powerful and relatively safe when running locally, hosting an agent on a cloud machine opens up a dangerous new attack surface.

Consider this nightmarish hypothetical exchange:

There are many things that would prevent this exact attack from working:

• We sanitize user inputs
• The LLMs are designed to detect and shut down malicious prompts
• We sanitize responses from the LLM
• We sanitize results from the agent

However, a sufficiently clever actor can bypass all of these safeguards and fool the agent into spilling the beans. We cannot rely on application level safeguards to contain the agent’s behavior. It is safer to assume that whatever the process can “see”, it can send over to the user.

What if there wasn’t a secret file on the machine at all? That is a good idea, and we should be very careful about what lives on the machine that the agent runs on but all machines have their secrets - networking information, environment variables, keys, stuff needed to get the machine running.

There will always be files on the system that we do not want the agent process to have access to. And if the process tries to access these files, we do not want to rely on the application code to save us. We want the kernel to say no.

In this article, we look at file hiding through the lens of the Linux kernel’s open syscall and see why it is a good idea to run agents inside containers.

The open syscall

All file calls lead to the open syscall, so this is the perfect place to start. You can try running

strace cat /etc/hosts

And see the openat syscall being invoked when running cat.

We will now go over the open syscall and see all the ways it can fail. Each failure mode leads naturally to a different way to conceal a file and we will use this to motivate how one could create a “sandbox” for a process.

Coming up:

1. What the open syscall does under the hood
2. Where this call can fail
3. Use these failure modes to understand how to conceal files

Under the hood

There is some unwrapping to do here but we can start at open.c

This is a tiny function:

SYSCALL_DEFINE4(openat, int, dfd, const char __user *, filename, int, flags,
        umode_t, mode)
{
    if (force_o_largefile())
        flags |= O_LARGEFILE;
    return do_sys_open(dfd, filename, flags, mode);
}

Which leads us down the following rabbit hole:

• do_sys_open
• do_sys_openat2
• do_filp_open
• path_openat

The heavy lifting seems to happen in the path_openat function. Let's look at some code here:

static struct file *path_openat(struct nameidata *nd,
            const struct open_flags *op, unsigned flags)
{
    //... initialization code (removed for brevity)
    if (unlikely(file->f_flags & __O_TMPFILE)) {
    //...error handling code (removed for brevity)
    } else {
        const char *s = path_init(nd, flags);
        while (!(error = link_path_walk(s, nd)) &&
               (s = open_last_lookups(nd, file, op)) != NULL)
            ;
        if (!error)
            error = do_open(nd, file, op);
        terminate_walk(nd);
    }
    //...cleanup code (removed for brevity)
}

Three things need to happen in order for the open call to succeed:

• path_init
• link_path_walk
• do_open

Each of these calls could fail. Let’s examine each of these in reverse chronological order and see the method of file concealment each one reveals.

do_open fails - "Late NO"

The do_open function handles the last step of the open() call. At this point, the kernel has already resolved the path and knows the file exists—it's now determining whether the calling process has permission to open it.

In the source code, we see that the main flow from do_open calls may_open which leads to a series of permission checks and a mismatch means -EACCES : permission denied.

This gives us the familiar chmod way of hiding a file:

# Create a test file
echo "super secret stuff" > secret.txt

cat secret.txt
# → works fine

#remove permissions
chmod u-r secret.txt
cat secret.txt # Permission denied

This is the simplest way to "hide" a file from a regular user.

What if we fail earlier?

link_path_walk fails - "Middle NO"

The link_path_walk function handles pathname resolution before do_open. Its job is to traverse the filesystem hierarchy from start to finish, validating both that the path exists and that the process has permission to traverse it.

When walking through /tmp/demo/a/secret.txt", the function:

1. Splits the path into components
2. Starts at the root (for absolute paths) or current directory (for relative paths)
3. For each directory component:

• Checks execute (search) permission - you need +x on a directory to traverse through it
• Looks up the next component
• Checks if anything is mounted over this directory and crosses the mount if needed

The mount check is crucial. After entering each directory, the kernel checks if a different filesystem has been mounted at that location. If so, it crosses into the mounted filesystem. This gives us a way to "hide" files - by mounting something over a directory in the path, we can make the original contents inaccessible.

Consider this example:

[abhinav@ubuntu ~]$ mkdir -p /tmp/demo/a /tmp/demo/cover
[abhinav@ubuntu ~]$ echo "top secret!" > /tmp/demo/a/secret.txt
[abhinav@ubuntu ~]$ cat /tmp/demo/a/secret.txt
top secret!
[abhinav@ubuntu ~]$ sudo mount --bind /tmp/demo/cover /tmp/demo/a
[abhinav@ubuntu ~]$ cat /tmp/demo/a/secret.txt
cat: /tmp/demo/a/secret.txt: No such file or directory

Here's what happens during path resolution before and after the mount:

Before Mount

After Mount (mount --bind /tmp/demo/cover /tmp/demo/a)

The critical difference is at Step 3: when the kernel checks if "a" is a mount point, it finds that it is. This triggers __traverse_mounts() to redirect the path from /tmp/demo/a/ to /tmp/demo/cover/. Since /tmp/demo/cover/ is empty, the file lookup on the next iteration fails with -ENOENT.

The original secret.txt still exists on disk in /tmp/demo/a/, but it's unreachable through normal path resolution - it's been "masked" by the mount. This is our second way of hiding a file.

What if we changed things even earlier?

path_init - "Early NO"

Remember we said in the previous section that when resolving absolute paths, the link_path_walk function starts at the root? Does this mean the root of the host machine's filetree? Let's investigate.

Here's a skeleton of the link_path_walk function:

static int link_path_walk(const char *name, struct nameidata *nd)
{
   // Walks through each component of the path, starting from nd->path
   // nd->path was set by path_init()
   //
   // For each component (e.g., "tmp", "demo", "file"):
   //   1. Looks it up in the current directory (nd->path.dentry)
   //   2. Checks if it's a mount point (calls traverse_mounts)
   //   3. Updates nd->path to move into that directory
   //   4. Continues until all components are processed
}

The starting point of the walk is nd->path which is set by the path_init function! And digging a little deeper,

• path_init() calls set_root() which sets nd->root to current->fs->root see this
• nd_jump_root() sets nd->path to this new root see this
• And then link_path_walk starts from nd->path

So the walk starts from current->fs->root. But what is this? It turns out every process has its own idea of what the root of the filesystem is, and this is stored in current->fs->root. For pid 1 init, this is the "actual" root of the filetree, and since child processes inherit this root from parent processes, this is true by default for most processes. However, it can be changed!

The chroot (change root) system call updates current->fs->root to point to a different directory. So we can use this to change where the path walk starts from! The main idea is, if we change the root of a process to /some/dir the process can not see anything "above" /some/dir in the file system since the path_walk will always start from /some/dir.

This is how a chroot jail works.

chroot gives us a third way of concealing a file!

Is there more?

There's another layer to this story: mount namespaces. Remember how in the previous section we saw that traverse_mounts() checks for mount points during the path walk? When it does this, it's actually only looking at mounts visible to the current process (not all the mounts). This is because each process belongs to a mount namespace.

A mount namespace is essentially a list of all mounts visible to processes in that namespace and different namespaces can have completely different sets of mounts.

This adds an interesting twist to our earlier mount masking example. When we did:

sudo mount --bind /tmp/demo/cover /tmp/demo/a

That mount was added to the default mount namespace, affecting ALL processes in that namespace. Maybe we don't want to do that. We could use mount namespaces!

# Create a new mount namespace for just this process
sudo unshare --mount bash

# Now add the masking mount - it only exists in this namespace!
mount --bind /tmp/demo/cover /tmp/demo/a

# In this shell, the file is hidden
cat /tmp/demo/a/secret.txt
# cat: /tmp/demo/a/secret.txt: No such file or directory

# But in another terminal (different namespace), it's still visible!
# (in another terminal, or exit out of the current one)
cat /tmp/demo/a/secret.txt
# top secret!

We saw three ways the kernel can deny file access:

• Permission bits (chmod)
• Mount masking - affects all processes unless you use a mount namespace
• Changing root (chroot) - good but can be escaped with some tricks

What if we combined the last two? We could:

1. Create a new mount namespace (so our mounts don't affect others)
2. Set up custom mounts (only visible in our namespace)
3. Change the root (so absolute paths start from our chosen directory)

This combination would give us complete control over what files a process can see since it happens even before path_init runs!

Is this just containerization?

Yes! This is exactly how container technologies like Docker, Podman, and containerd work at the kernel level. A great article that covers this is Containers from Scratch by Eric Chiang.

When you run a Docker container, Docker does the following:

1. Spawns a new process with isolated namespaces (including mount namespace) using clone with namespace flags
2. Switches the root filesystem using pivot_root (similar to chroot)
3. Configures the container's filesystem view through mount operations within the new namespace

Conclusion

We traced through the open syscall and found three places where the kernel can deny file access and each gave us a different way to hide files:

1. Late NO (do_open) - Permission checks
2. Middle NO (link_path_walk) - Mount redirections during path traversal
3. Early NO (path_init) - Changing where the walk starts and what mounts the process sees

Then, we motivated the idea of combining mount namespaces with root changes which is at the core of containerization technologies - the underlying technology that is used to make sandboxes for agents.

When a process has its own mount namespace and a different root, it can't access files outside that root—they don't exist in its filesystem view. The kernel enforces this at path resolution time, making it impossible for userspace to bypass. At Greptile, we run our agent process in a locked-down rootless podman container so that we have kernel guarantees that it sees only things it’s supposed to.