Filesystem Enumeration via Interactive Deletion
Granting AI agents the ability to execute the rm command within a sandbox seems benign, especially on read-only filesystems. However, if the sandbox doesn't strictly control command flags, standard Unix tools can be weaponized for reconnaissance.
This post analyzes how the interactive mode of rm can be used to map a filesystem without read permissions, essentially turning a deletion tool into an enumeration tool.
The Side-Channel Vulnerability
The core issue is that various rm flags prioritize user feedback over secrecy. In restricted environments like AI agent sandboxes, this verbosity creates a side channel.
- Interactive Flags (
-i,-iR): Cause prompts that reveal file/directory names and types, even when deletion is declined. - Verbose Flags (
-v,-rfv): Show whatrmattempts to process, revealing filesystem structure and protection boundaries.
This works even on read-only filesystems because the output appears before any deletion attempt occurs.
Systematic Filesystem Enumeration
An agent can follow a top-down discovery process to map the environment using only the rm command.
Phase 1: Architecture Mapping
The first step is often a broad sweep to identify mount points and top-level directory layout.
rm -rfv --no-preserve-root --one-file-system /
This command provides an overview of the system layout by attempting (and failing) to process the root directory, leaking information about its contents in the verbose output.
Phase 2: Targeted Directory Enumeration
Once interesting directories are discovered, rm -iR is used to map the structure in detail. In an automated environment, the agent can be configured to auto-decline all prompts (sending n to every question).
rm -iR /agent
Resulting Prompts:
rm: descend into directory '/agent'?
rm: descend into directory '/agent/vendored'?
rm: descend into directory '/agent/.venv'?
rm: descend into directory '/agent/.venv/bin'?Phase 3: Deep File Discovery
By targeting specific subdirectories, the attacker can identify critical executables or configuration files.
rm -iR /agent/.venv/bin
Even if the filesystem is read-only, the error message confirms the file's existence:
rm: cannot remove '/agent/.venv/bin/mcp-server': Read-only file systemTechnical Details
The vulnerability stems from the order of operations in the tool's logic. To prompt the user, rm must first stat the entry to determine if it is a directory or a file.
A simplified strace output reveals the information leakage:
lstat("/app/src", {st_mode=S_IFDIR|0755, ...}) = 0
write(2, "rm: descend into directory '/app/src'?", 38)
read(0, "n\n", 1024) = 2The tool confirms existence (lstat returns 0) and immediately writes to Standard Error. This occurs before any unlink or rmdir syscall is attempted.
Prompt Indicators
- Directory exists:
rm: descend into directory '/path'? - File exists:
rm: remove regular file '/path'? - Symlink exists:
rm: remove symbolic link '/path'? - Path missing:
rm: cannot remove '/path': No such file or directory - Read-only:
rm: cannot remove '/path': Read-only file system
Mitigation
Defending against this class of side-channel attack requires treating tool output as sensitive information.
- Force Non-Interactive Mode: Automated agents should never run interactive commands. Enforce flags that suppress prompts (e.g, wrap the command to always include
-f). - Output Suppression: If the agent does not need the output of a cleanup task, redirect it to
/dev/null. - Strict Capability Restrictions: Use kernel-level or container-level restrictions (like AppArmor or Seccomp) to prevent the agent from even attempting to
statpaths outside its designated workspace.
What This Means
Verbosity is often a UX feature that doubles as a security vulnerability in automated environments. By carefully controlling tool flags and output redirection, developers can close side channels that reveal filesystem structure to potentially compromised agents. The ability to run any standard utility with arbitrary flags is often enough to bypass simple path-based permissions.