OS and Application Security – chroot Demo

Objective

The purpose of this lab is to understand how chroot (change root) creates a restricted filesystem environment. It changes the root directory of a process so that it sees only a specific folder as its entire filesystem. This demonstrates the basic idea behind modern container technologies such as Docker.

Key Activities

Created a host secret file (/host_secret.txt) to simulate sensitive data. Installed BusyBox Static to provide a lightweight shell without external library dependencies. Built a chroot jail and launched a shell inside it using the chroot command. Tested the sandbox by listing directories, attempting directory traversal (cd ../../..), and trying to access the host secret file.

Key Observations

The process could only see files inside the chroot jail. Attempts to move outside the jail using .. were blocked because the kernel treated the jail as the process’s root (/). The host secret file could not be accessed, demonstrating basic filesystem isolation. Commands such as nano, python3, or grep failed because their executables and required libraries were not present inside the jail.

Security Limitation

Although chroot restricts filesystem access, it is not a true security mechanism. It only changes path resolution and does not isolate processes, users, namespaces, or privileges. A process running with root privileges can potentially escape the jail.

Privilege Escape (Double-Chroot Escape)

If a user inside the chroot jail has root privileges, they can:

Keep a file descriptor pointing to the original root directory. Perform another chroot into a subdirectory. Use the saved file descriptor to navigate back outside the jail. Reach the real host root and execute another chroot, completely escaping the sandbox.