5-Layer Resource Isolation — Enterprise Security Architecture

[admin]

Shared hosting is inherently insecure — unless you isolate users properly. Panelica implements 5 layers of isolation that most panels require expensive add-ons to match.

The Shared Hosting Security Problem​

On traditional shared hosting, hundreds of users share the same server. If one user's website is compromised:

• Cross-site contamination: Attacker reads other users' files (open_basedir bypass exploits exist)
• Resource exhaustion: Malicious script forks 10,000 processes, crashes server
• Privilege escalation: User gains root access via kernel exploit
• Data theft: Attacker dumps /etc/passwd, cracks passwords, logs in as other users

Traditional panels rely on Unix permissions (UID/GID). But that's 1970s security. Modern threats require modern isolation.

cPanel's Security Model (And Its Gaps)​

cPanel's default isolation:

• PHP-FPM per-user pools (open_basedir)
• Apache suEXEC (runs CGI as user UID)
• ModSecurity (Web Application Firewall)

Gaps:

• No CPU/RAM/I/O limits → one user can crash server
• No PID limits → fork bomb kills server
• No namespace isolation → users see each other's processes
• SSH access = full filesystem visibility (/home/otheruser/ accessible)

cPanel's solution: CloudLinux with CageFS.

CloudLinux adds:

• LVE (Lightweight Virtual Environment) — CPU/RAM/I/O limits
• CageFS — chroot jail per user

Cost: per server.

Why should isolation be a paid add-on?

Panelica's 5-Layer Isolation (Included Free)​

Panelica combines 5 isolation technologies that work together to prevent cross-user attacks and resource exhaustion.

Layer 1: Cgroups v2 (Resource Limits)

Every user gets a dedicated systemd slice with hard resource limits:

Path: /sys/fs/cgroup/panelica.slice/panelica-user.slice/panelica-user-{username}.slice/

Limits:
- cpu.max: 2 cores (200000 per 100ms)
- memory.max: 2GB
- io.max: 100MB/s read, 50MB/s write
- pids.max: 1024 processes

What this prevents:

• CPU exhaustion: User can't consume more than allocated cores
• Memory bombs: Process killed at 2GB, doesn't OOM the server
• Fork bombs: Limited to 1024 processes (not 10,000)
• I/O starvation: Disk I/O capped (prevents resource abuse)

Comparison:

• cPanel default: No limits
• cPanel + CloudLinux: LVE limits ()
• Panelica: Cgroups v2 limits (free)

Layer 2: Linux Namespaces (Process + Filesystem Isolation)

Each user's processes run in isolated namespaces:

• PID namespace: User only sees their own processes (ps aux shows only their PIDs)
• Mount namespace: Custom filesystem view (CageFS-like, virtual /etc/, /usr/, /tmp/)

Path: /opt/panelica/var/namespaces/{username}/

Virtual rootfs:
/bin → symlink to /opt/panelica/bin/
/etc → filtered (only user's configs)
/tmp → isolated tmpfs (not shared /tmp)
/home → only user's home directory
/usr → read-only system binaries

What this prevents:

• Process spying: User can't see other users' processes
• /tmp attacks: User's /tmp is private (no symlink attacks)
• Config leaks: /etc/ only shows sanitized configs (no /etc/shadow)

Comparison:

• cPanel default: Shared /tmp, visible processes
• cPanel + CloudLinux: CageFS ()
• Panelica: Namespaces (free)

Layer 3: SSH Chroot Jails

When users log in via SSH/SFTP, they're jailed to their home directory:

# sshd_config for user 'john'
Match User john
 ChrootDirectory /home/john
 ForceCommand internal-sftp # SFTP-only mode
 X11Forwarding no
 AllowTcpForwarding no

Modes:

• SFTP-only: User can transfer files but can't execute commands
• Full bash + chroot: User gets shell but can't escape /home/john/

What this prevents:

• Directory traversal: cd /home/otheruser/ fails (sees / as /home/john/)
• Command injection: SFTP-only mode disables shell execution

Comparison:

• cPanel default: SSH access = full filesystem
• cPanel jailshell: Limited (no PHP, no MySQL client)
• Panelica: True chroot jail

Layer 4: PHP-FPM Per-User Per-Version Pools

Each user gets dedicated PHP-FPM pools (one per PHP version they use):

Service: [email protected]

Config: /opt/panelica/etc/php-fpm-users/john/8.3/pool.d/john.conf

[john_php83]
user = john
group = john
listen = /opt/panelica/var/run/php-fpm-8.3-john.sock

php_admin_value[open_basedir] = /home/john/:/opt/panelica/var/tmp/
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen
php_admin_value[upload_tmp_dir] = /home/john/tmp/
php_admin_value[session.save_path] = /home/john/tmp/sessions/

What this prevents:

• File access outside home: open_basedir restricts to /home/john/
• Command execution: exec(), system() disabled
• Shared tmp exploits: Upload/session files in user's private /home/john/tmp/

Comparison:

• cPanel: PHP-FPM pools (but shared /tmp/)
• Plesk: PHP-FPM pools
• Panelica: Per-user per-version pools + isolated /tmp/

Layer 5: Unix Permissions (UID/GID Isolation)

Each user gets a unique UID/GID (not shared www-data):

# User 'john' created with UID 10001
useradd -u 10001 -g 10001 -d /home/john -s /bin/bash john

# Home directory permissions
chmod 700 /home/john/
chown -R john:john /home/john/

# Files written by panel use UserContextService:
WriteFileAsUserSudo(username, path, data, 0644)
# → Writes as root to temp file → chown to john:john → mv to path

What this prevents:

• File permission bypass: Even if open_basedir is bypassed, Unix DAC denies access
• World-readable files: chmod 700 on home (other users can't read)

Comparison:

• All panels: Unix permissions
• Panelica: chmod 700 home dirs (stricter)

How the 5 Layers Work Together​

Attack Scenario 1: Compromised WordPress Plugin

Attacker uploads malicious PHP file (shell.php) to /home/john/public_html/wp-content/uploads/.

Attempted attack:

<?php system('cat /home/alice/wp-config.php'); ?>

Layer 4 (PHP-FPM) blocks: system() is in disable_functions. Script dies.

Attacker tries:

<?php readfile('/home/alice/wp-config.php'); ?>

Layer 4 (PHP-FPM) blocks: open_basedir restricts to /home/john/. Access denied.

Attacker tries:

<?php
// open_basedir bypass exploit (CVE-2024-XXXX)
ini_set('open_basedir', '/');
readfile('/home/alice/wp-config.php');
?>

Layer 5 (Unix Permissions) blocks: PHP runs as UID 10001 (john). /home/alice/ is chmod 700, owned by UID 10002 (alice). Read denied.

Result: Attack fails at 3 layers.

Attack Scenario 2: Fork Bomb

Attacker runs fork bomb command.

Layer 1 (Cgroups) blocks: After 1024 processes, pids.max is reached. Kernel refuses to fork. Server unaffected.

Attack Scenario 3: Memory Exhaustion

Attacker allocates huge memory.

Layer 1 (Cgroups) blocks: After 2GB allocated, memory.max triggers OOM killer. Process killed. Server unaffected.

Attack Scenario 4: SSH Lateral Movement

Attacker gains SSH access to user 'john' via stolen password.

Attempted:

john@server:~$ cd /home/alice/
bash: cd: /home/alice/: Permission denied

john@server:~$ ls /home/
ls: cannot open directory '/home/': Permission denied

john@server:~$ ps aux | grep alice
# No processes visible (Layer 2: PID namespace)

john@server:~$ cat /etc/shadow
cat: /etc/shadow: No such file or directory # Layer 2: filtered /etc/

Result: Attacker trapped in chroot jail.

Performance Impact of Isolation​

Question: Do 5 layers of isolation slow down the server?

Answer: Negligible overhead (~1-2%).

• Cgroups v2: Kernel overhead < 0.1% (eBPF-based accounting)
• Namespaces: Zero runtime overhead (set at process creation)
• SSH chroot: No overhead (OpenSSH native feature)
• PHP-FPM pools: Same overhead as cPanel (all panels use FPM)
• Unix permissions: Zero overhead (kernel DAC checks are always active)

Benchmark (Apache Bench, 10,000 requests):

Configuration	Requests/sec
No isolation	5,432
5-layer isolation	5,348
Difference	-1.5%

Security benefit: 1000%. Performance cost: 1.5%.

Comparison: Panelica vs. cPanel vs. Plesk​

Isolation Layer	cPanel (Free)	cPanel + CloudLinux	Plesk	Panelica
CPU Limits		LVE		Cgroups v2
Memory Limits		LVE		Cgroups v2
I/O Limits		LVE		Cgroups v2
PID Limits		LVE		Cgroups v2
PID Namespace
Mount Namespace		CageFS
SSH Chroot	jailshell (limited)	CageFS
PHP-FPM Pools
Isolated /tmp		CageFS
Unix Permissions

Panelica provides CloudLinux-level isolation at 1/3 the cost.

Additional Security Features​

Beyond the 5 isolation layers, Panelica includes:

• ModSecurity WAF: OWASP Core Rule Set preconfigured
• ClamAV antivirus: On-demand and scheduled file scanning
• Fail2ban: Automatic IP blocking for brute-force attacks
• Security Advisor: 50+ checks (outdated PHP, weak passwords, open ports, misconfigured SSL)
• Two-factor authentication (TOTP): Panel login protection
• IP whitelist/blacklist: Restrict panel access by IP
• Audit logs: Every user action logged (file changes, domain edits, SSH logins)

Use Cases​

1. Web Hosting Providers

Host 500+ customers on one server. If one customer's site is hacked, others are unaffected (5-layer isolation).

2. Agencies Managing Client Sites

Each client gets isolated account. Client can't see other clients' files even with SSH access.

3. SaaS Platforms

Each SaaS customer gets dedicated cgroup slice (CPU/RAM limits). One customer's traffic spike doesn't crash others.

Monitoring Isolation (Real-Time)​

Panelica's dashboard shows per-user resource usage:

User 'john':
 CPU: 1.2 cores / 2.0 allocated (60%)
 Memory: 1.5GB / 2.0GB (75%)
 Disk I/O: 25MB/s read, 10MB/s write
 PIDs: 342 / 1024 (33%)

If user hits limits, panel shows warning:

 User 'john' reached memory limit (2GB). Process 'php-fpm' killed.

Alerts sent via email, Telegram, Slack, or webhook.

Pricing​

Visit our pricing page for current plans and pricing.

Getting Started​

Install Panelica:

curl -sSL https://latest.panelica.com/install.sh | bash

Create a user:

Users → Add User → Set resource limits (CPU, RAM, I/O, PIDs)

Verify isolation:

# Check cgroup limits
cat /sys/fs/cgroup/panelica.slice/panelica-user.slice/panelica-user-john.slice/memory.max

# Check namespace
sudo unshare -m -p --fork --mount-proc chroot /opt/panelica/var/namespaces/john/ /bin/bash

Full Security Features | Documentation | Pricing

Enterprise-grade isolation. No CloudLinux subscription. No hidden costs.