TNS Panel
Security model
Security is the first design priority, ahead of speed and convenience. This page tells a buyer what the panel isolates, how, and what it does not do. It is a summary of design decisions, not a certification.
Isolation between customers
| Layer | Mechanism |
|---|---|
| Identity | One UNIX user per client account. All sites of one client share that user. |
| Web code | Each client runs its own PHP-FPM master (per client and PHP version), under its own user, with its own opcache. open_basedir confines PHP to the client's directories, and disable_functions blocks process execution and similar escapes. |
| Resources | Each client gets its own systemd slice with CPU, memory, process and IO limits taken from the plan (cgroup v2; cgroup v1 on AlmaLinux 8, where the panel uses the v1 equivalents). Requires a License. |
| Filesystem | /home can be traversed but not listed, so one client cannot enumerate others. Disk quotas (space and inodes) are enforced by the kernel. Every file operation done by the panel on a client's behalf is confined to that client's home. |
| Processes | /proc is mounted so that a client cannot see other users' processes. Each client has a private /tmp. |
| Shell and cron | Shell sessions and cron jobs run in a jail built from namespaces: read-only system, only the client's home, a trimmed user list and no view of other clients. Failure to build the jail means the command does not run. SSH port forwarding and tunnels are disabled for clients. |
| Databases | Names carry the client prefix; users get privileges on their own databases only, and cannot grant access. Grants are escaped so that a name such as shop_ cannot match shop2_.... |
Authenticated users can only send as their own address; DKIM signs only for the envelope sender's domain; the mail() function and submission are rate-limited per client. | |
| DNS and certificates | A zone, site or mail domain cannot be created inside another client's domain tree, and the node's own names are reserved. |
Panel hardening
- No generic "run command" anywhere. The API runs as an unprivileged user and never executes anything. A separate root agent exposes a fixed list of domain operations, validates every argument, passes arguments to programs directly (never through a shell), and re-checks ownership itself instead of trusting the API.
- The API is not on a TCP port. It listens on a UNIX socket only. Remote access goes through the admin web port with a token.
- Two interfaces on two ports. Each rejects the other's role; the admin port can be firewalled to your own addresses.
- Second factor is mandatory for admins and resellers. Session cookies are
Secure,HttpOnly,__Host-prefixed and tied to a CSRF token. - Login protection. Failed logins are slowed per account (increasing waits, never a hard lock that an attacker could use to lock you out) and banned per source address at the firewall.
- Secrets. Passwords for panel users are hashed with Argon2id; mailbox, FTP and database passwords are hashed by the service that verifies them. MD5 is never used. Things that must stay reversible (certificate keys, API tokens of third parties, backup credentials) are encrypted with a master key kept in a root-only file outside the database.
- Signed software. Panel updates and service modules are Ed25519-signed; the node holds the public key and rejects anything else. The panel binary is statically linked and is not compiled on your server.
- Audit. Every action is recorded (who, what, when, from where, on what), including admins, and can be exported to your own syslog/SIEM over verified TLS.
- Cluster. Nodes talk over mutual TLS with a private certificate authority whose key lives only on the founder. Both sides verify the other, and verify which node it is.
Backups and data protection
Backups are encrypted and deduplicated (restic). The node backs up all accounts, including suspended ones. Backup credentials are stored encrypted. A restore always copies into the client's home with the client's ownership, never following links the client placed.
What the panel does not promise
- Sites of the same client are not isolated from each other. They share one UNIX user. A compromised site can reach the other sites of that client. Isolation is between clients.
- It is shared hosting. Clients share one kernel. A kernel vulnerability is outside what the panel can contain. Keep nodes updated and consider a reboot window.
- Resource limits are a paid feature. Without a License, per-client CPU/RAM/IO/process limits are not applied, and one client's workload can slow others. Static files served directly by the web server are not charged to the client's cgroup.
- Free tier handler. The Free tier today runs PHP with fcgid and suexec, which is slower and gives a shorter isolation chain than per-client PHP-FPM (the wrapper lives in a directory the client owns). The move to PHP-FPM on Free is Coming soon.
- SELinux is disabled on hosting nodes. The isolation above does not rely on it, but it is not an extra layer you get.
- Unprivileged user namespaces must stay enabled for the jail; this is the default on the supported distributions.
- A console account is more trust than SFTP-only. Enable the console only for clients who need it.
- Content you host is yours to patch. The malware scanner detects known signatures and reports; it does not remove files and is not a substitute for updated applications. The WAF is a paid feature.
- Mail reputation is shared. Per-client hourly limits and per-sender rules reduce the chance that one client damages the IP reputation for all, but a new IP still needs warm-up.
- Cloud backup and storage tokens (OAuth) can be revoked by their owner, and the backup silently stops until refreshed; the advisor reports destinations that stopped running.
- The software was reviewed with several independent reviewers and checked on real servers, and this is a young product. Treat the first months as you would any new infrastructure software: staged rollout, your own backups, and a plan to fall back.