In this lesson, you will learn how to use Control Groups (cgroups) to architect a sandbox that restricts the resources a user’s session can consume, effectively containing potential breaches.
The Logic of Resource Containment
While traditional permissions handle file and process access, they do not inherently limit the "blast radius" of a compromised user account. By using cgroups v2, you can place a user’s entire login session into a dedicated slice. If an attacker gains entry, they are physically constrained by the kernel from monopolizing CPU cycles or exhausting system memory, preventing them from destabilizing the host or performing a Denial of Service (DoS) attack on other system services.
Implementing Session-Based Sandboxing
Modern systemd-based distributions handle cgroup delegation automatically. To sandbox a user, you define a slice configuration. When a user logs in, the system assigns their session processes to a unique cgroup branch: /sys/fs/cgroup/user.slice/user-1001.slice/.
You can enforce constraints by modifying the systemd user slice properties. For example, to cap a user's memory usage and prevent them from spawning excessive background processes, you would create a drop-in configuration:
# /etc/systemd/system/user-1001.slice.d/sandbox.conf
[Slice]
MemoryMax=2G
CPUQuota=20%
TasksMax=50
Once applied via systemctl daemon-reload, any process started within that user's session—including SSH tunnels or background shell tasks—is strictly governed by these limits. Because the kernel enforces these boundaries at the cgroup level, a process exceeding its memory limit will be OOM-killed (Out of Memory) before it can impact the rest of the kernel or adjacent user sessions.
Why This Matters
Sandboxing through cgroups provides a "hard" wall that supplements your PAM-based identity management. Even if an attacker uses compromised credentials to spawn thousands of malicious threads, the TasksMax setting ensures the system remains responsive, while MemoryMax ensures the integrity of shared system resources. By isolating user sessions, you turn a potentially catastrophic system-wide compromise into a manageable, contained incident.
Key Takeaway: Cgroups enable you to enforce strict resource quotas per user, ensuring that compromised accounts are mathematically unable to impact system-wide stability or monopolize critical hardware.