Using chroot to Restrict Linux Applications for Enhanced Security
Introduction
It’s surprising how many old-school, mainframe-style shell applications are still powering critical systems today. Once you’ve worked with one, you start spotting them everywhere—tucked inside modern infrastructure, often without the isolation or security they deserve.
Here’s the catch: modern Linux distributions ship with thousands of utilities. That’s overkill for a single-purpose app—and each one adds another potential vulnerability. If you’re only trying to run one small application, why leave the doors open to the rest of the system?
This is where Linux’s chroot capability becomes an underrated powerhouse. It’s not new. It’s not fancy. But it does one thing extremely well: it isolates an application from the rest of the system—and that’s exactly what you want when you’re locking things down.
Table of Contents
- Introduction
- Understanding chroot
- Why Use chroot with SSH
- Risks and Limitations of chroot
- Final Thoughts
Understanding chroot
At its core, chroot is a surgical tool in the Linux toolbox. It lets you create a fake root directory (/) and restrict a process to only see that slice of the filesystem. Outside of that? It might as well not exist.
This is incredibly powerful—because if a user or process can’t see it, they can’t touch it, abuse it, or exfiltrate data from it.
Yes, it’s limited. It won’t secure your networking stack. It doesn’t stop privilege escalation. But for file-level isolation? chroot is a solid, lightweight containment method, especially when you don’t want to spin up a full-blown container or VM.
Why Use chroot with SSH?
SSH access is one of the biggest attack surfaces on any Linux server. Once you’re in, you’re in—and that includes everything in the path, environment, and filesystem. That’s too much exposure if all a user needs is to run one script.
With chroot, you flip the script.
You can lock a user down to a tiny, hand-curated environment. No shells, no tools, no funny business—unless you explicitly put it there. Need ls? Add it. Need sleep? Add it. Need python3? Only if you’re brave.
I’ve had setups where even the most basic commands weren’t available inside the jail until I manually copied them in—along with every single shared library they rely on. It’s tedious at first, but that’s kind of the point. You’re building a minimalist safe zone, and every binary you exclude is a risk you don’t have to manage.
Risks and Limitations of chroot
Let’s be blunt: chroot is not a magic bullet.
It doesn’t protect against privilege escalation. It won’t isolate processes or manage resources like containers do. And it absolutely won’t maintain itself.
The biggest headache? Everything inside the jail has to be copied manually. That includes binaries and their shared libraries—no symlinks allowed. When you patch your system, those copies don’t update themselves. If you forget to rebuild your chroot environment, you’re running old, vulnerable code—and that’s worse than no isolation at all.
So yes, chroot is useful. But only if you’re disciplined about maintaining it.
How It Works: A Practical Example
I recently helped with a project where remote users needed SSH access—but only to a specific script. They didn’t need a shell. They didn’t need the full filesystem. They needed one thing: run a script, get the output, and get out.
Perfect chroot use case.
Creating the Isolated Filesystem
We set up a jail at /home/jail, then created a dedicated user named app_richard. The jail had a basic directory structure like this:
1
2
3
4
5
6
/home
├── jail
│ ├── app
│ ├── home
│ │ └── app_richard
├── app_richard # (outside the jail)
Everything under /home/jail was owned by root. That’s required—SSH won’t chroot a user into a directory they own. (Security 101.)
Setting Up the Limited Application
On login, we forced SSH to run a script: launch_app.sh. Here’s what it did:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/bash
echo "==========================================="
echo " Welcome to the Chroot Test App"
echo "==========================================="
echo ""
echo "You are currently in: $(pwd)"
echo "Listing contents of your home directory:"
echo ""
ls -la /home/app_richard
echo ""
echo "Test complete. Disconnecting now..."
sleep 3
exit 0
Nothing fancy—but it needed a few things to work: bash, ls, sleep, and all their shared libraries. We used ldd to identify what had to be copied:
1
ldd /usr/bin/bash
After gathering all the binaries and libraries, the jail looked something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/home
├── jail
│ ├── app
│ │ └── launch_app.sh
│ ├── bin
│ │ └── bash
│ ├── home
│ │ └── app_richard
│ ├── lib64
│ │ ├── ld-linux-x86-64.so.2
│ │ ├── libcap.so.2
│ │ ├── libc.so.6
│ │ ├── libdl.so.2
│ │ ├── libpcre2-8.so.0
│ │ ├── libpthread.so.0
│ │ ├── libselinux.so.1
│ │ └── libtinfo.so.6
│ └── usr
│ └── bin
│ ├── ls
│ └── sleep
We also created a group called app_users so we could control access through SSH config.
SSH Configuration Changes
Here’s the SSH block we added to /etc/ssh/sshd_config:
1
2
3
4
5
6
Match Group app_users
ChrootDirectory /home/jail
ForceCommand /app/launch_app.sh
PermitTTY no
AllowTcpForwarding no
X11Forwarding no
After restarting SSH:
1
sudo systemctl restart sshd
The user logs in, runs the script, and gets kicked out. Mission accomplished.
1
2
3
4
5
6
7
8
9
10
11
12
===========================================
Welcome to the Chroot Test App
===========================================
You are currently in: /home/app_richard
Listing contents of your home directory:
total 0
drwxr-xr-x. 2 1003 1004 6 Jul 18 01:25 .
drwxr-xr-x. 3 0 0 18 Jul 18 01:25 ..
Test complete. Disconnecting now...
Final Thoughts
Would I recommend chroot? Yes—but only for the right jobs.
If I’m working with a self-contained app, a legacy script, or a third-party tool that doesn’t need system access, chroot is a great way to put it in a box and throw away the key. It’s lightweight, transparent, and doesn’t require container runtimes or kernel modules.
But let’s not pretend it’s a silver bullet. chroot only isolates the filesystem. It doesn’t lock down memory, processes, networking, or user privileges. And if you’re not keeping the chroot up to date? You’ve just created a security theater.
Used correctly, chroot is powerful. Used lazily, it’s a liability.
Need Help with Linux Security or Isolation?
I help businesses streamline servers, secure infrastructure, and automate everything from deployment to disaster recovery. Whether you’re isolating applications, managing access, or hardening critical systems—I’ve been there, and I can help.
📬 Drop a comment or email me. For more tools, tutorials, and technical deep dives, visit sebostechnology.com.
☕ Like this kind of content?
If this helped you lock something down—or avoid another late-night fire drill—consider buying me a coffee:
Your support helps me keep sharing practical Linux security tactics that actually work.