Shared hosting was built on a dangerous assumption: users can be trusted not to interfere with each other. A single Linux server, shared /tmp directory, shared PHP processes, shared everything. If one user's site is compromised, every other user on that server is exposed.
This model worked in 2005 when hosting customers were mostly hobbyists running personal blogs. It does not work in 2026 when servers host e-commerce platforms processing payments, SaaS applications handling sensitive data, and business-critical infrastructure that cannot tolerate cross-user contamination.
Zero-trust hosting means assuming every user's environment will eventually be compromised — and building isolation so thorough that a breach in one account cannot reach any other.
In This Article
- The Trust Problem in Traditional Hosting
- Panelica's Five-Layer Isolation Model
- Layer 1: Cgroups v2 — Resource Containment
- Layer 2: Linux Namespaces — Process and Filesystem Isolation
- Layer 3: SSH Chroot Jails — Restricted Shell Access
- Layer 4: PHP-FPM Per-User Pools — Application Sandboxing
- Layer 5: Unix Permissions — The Foundation
- What Isolation Cannot Do (And What You Must)
1. The Trust Problem in Traditional Hosting
On a standard shared hosting server, here is what User B can do if User A's account is compromised:
Traditional panels solve this partially with add-ons. cPanel relies on CloudLinux CageFS (additional license required). Plesk has basic chroot. Most open-source panels have no isolation at all.
Panelica solves it with five independent layers that work together, enabled by default, at no additional cost.
2. Panelica's Five-Layer Isolation Model
3. Layer 1: Cgroups v2 — Resource Containment
Cgroups v2 (control groups version 2) is a Linux kernel feature that limits, accounts for, and isolates resource usage. Panelica creates a dedicated cgroup slice for every user account.
Scenario: The Cryptocurrency Miner
4. Layer 2: Linux Namespaces — Process and Filesystem Isolation
Namespaces are a Linux kernel feature that creates isolated views of system resources. Panelica uses PID namespaces and Mount namespaces for every user.
- PID Namespace: User A cannot see User B's processes.
ps auxshows only their own processes. No process enumeration. No killing other users' processes. - Mount Namespace: User A's filesystem view is limited to their own directories. Sensitive system paths are not visible.
/procis filtered to show only the user's own PIDs.
Scenario: Process Enumeration Attack
ps aux | grep mysql and sees MySQL processes with command-line arguments — potentially including database names, socket paths, and configuration details. They run ls /home/ and see every username on the server. Social engineering or targeted attacks become trivial.
ps aux returns only the attacker's own processes. ls /home/ shows only their own home directory. They cannot enumerate users, discover services, or gather intelligence for lateral movement. From their perspective, they are the only user on the server.
5. Layer 3: SSH Chroot Jails — Restricted Shell Access
When users need SSH or SFTP access, Panelica provides two jail modes:
SFTP-Only Jail
User can only transfer files via SFTP. No shell access. No command execution. The user sees only their own home directory. This is the safest option for clients who only need to upload files.
Full Bash + Chroot Jail
User gets a full bash shell, but chrooted to a restricted filesystem. They can run commands, but cannot access paths outside their jail. System binaries are provided via bind mounts — read-only.
6. Layer 4: PHP-FPM Per-User Pools — Application Sandboxing
Most PHP security breaches happen through web applications — WordPress plugins, custom PHP scripts, file upload vulnerabilities. Layer 4 ensures that even when PHP code is compromised, the damage is contained.
Panelica creates a dedicated PHP-FPM pool for every user, for every PHP version they use:
Scenario: The File Upload Web Shell
www-data — the same user that runs all PHP on the server. The shell can read /home/userB/public_html/wp-config.php, accessing User B's database credentials. The attacker pivots from one compromised site to every site on the server.
john:john, not www-data. open_basedir restricts file access to /home/john/. disable_functions prevents exec() and system(). Even if the attacker has code execution, they are sandboxed inside John's environment with no way to reach Jane's files, Bob's database, or the system's configuration.
7. Layer 5: Unix Permissions — The Foundation
The simplest layer is also the most important. Every user account in Panelica gets:
- Unique UID/GID: Each user has a dedicated system user with a unique numeric ID. No shared groups.
- Home directory 700:
drwx------— only the owner can read, write, or enter. Other users cannot even list the directory contents. - Secure file creation: The panel writes configuration files through
WriteFileAsUserSudo()— the Go backend writes to a temp file as root, then chowns it to the user. No race conditions. No permission gaps.
8. What Isolation Cannot Do (And What You Must)
Five layers of isolation are comprehensive. They are not omnipotent. Here is what isolation does not cover:
Application Logic Flaws
If a WordPress plugin sends customer data to an attacker's server via an HTTP request, isolation does not prevent it. The request originates from within the user's legitimate sandbox. Your job: Vet plugins before installing. Monitor outbound traffic.
Credential Compromise
If a user's panel password is "password123", isolation does not help — the attacker logs in as the user with full permissions within that user's scope. Your job: Enforce strong passwords and 2FA.
Data Exfiltration Within Scope
A compromised account can exfiltrate all data within its own scope — its own databases, files, and emails. Isolation prevents cross-user damage, not within-user damage. Your job: Minimize data stored on the server. Encrypt sensitive fields.
Social Engineering
No amount of technical isolation prevents a user from being tricked into giving away their credentials or installing malicious software. Your job: Educate your users. Provide security awareness resources.
Zero-trust hosting is not about distrusting your users. It is about acknowledging reality: breaches happen, plugins have vulnerabilities, passwords get leaked, and humans make mistakes. The question is not "will something go wrong?" but "when it does, how much damage will it cause?"
With five independent isolation layers, the answer is: damage contained to a single user. With an attentive administrator, even that damage is caught and remediated quickly.
Five Layers of Isolation. Zero Extra Cost.
Every Panelica installation includes full 5-layer isolation by default. No add-ons. No premium tiers. No third-party dependencies.
Explore Panelica IsolationPanelica — because "trust but verify" should be "isolate and verify."