SHM security is a system of boundaries, not one checkbox

Who can act

Identity defines the first boundary

SHM serves root administrators, resellers, and hosting accounts, so every operation begins with who is asking and which resources that role owns. Authorization is enforced by server-side routes and resource loaders independently of what the interface displays.

Root can manage the server. A reseller is restricted to the reseller's accounts. An account user stays within that account. The same ownership checks are reused by the normal interface, public API, and AI Mode.

Authentication protects more than a page

Accounts can use two-factor authentication, account password controls, and IP access policies. Service-level allowed IP settings can narrow access where the workflow requires it. Root has separate controls for root authentication, two-factor protection, access policy, and SSH configuration.

Protected Mail extends stronger authentication to mail access. App passwords can be generated for compatible clients, displayed once, and revoked. Recent authentication activity helps users review how the protected account is being used without exposing stored password hashes.

Where work can happen

Files and shells need active isolation

Account file operations validate normalized paths, ownership, traversal, and link behavior. The web stack uses account-aware permissions and symlink controls. JailShell provides a managed command environment for accounts with shell access while keeping writable system areas outside the account boundary.

These controls must survive runtime updates. When a PHP or Node.js runtime changes, SHM updates the supported jail environment while preserving required read-only bindings.

Layer the web defenses

HTTP Guard, ModSecurity with supported rule sets, blocked-bot controls, domain restrictions, TLS, and security-aware web configuration cover different parts of the request path. A precise ModSecurity exclusion is different from disabling protection, and a URI policy is different from an account login restriction.

SHM keeps those controls separate so an operator can respond at the narrowest useful layer. Security works better when exceptions have a small blast radius and an understandable reason.

How authority is contained

Avoid root where the task does not need it

Podman workloads are managed rootlessly under the account identity. Node.js applications run as the account user. Database, file, terminal, log, and mail views return account-owned resources. This reduces the number of everyday operations that require server-root execution.

Server administration still requires root authority, but customer workflows use it only when the operation genuinely requires it.

Verify the lifecycle

Configuration generators validate output before applying it where supported, preserve previous state for rollback paths, and verify service status after lifecycle actions. Logs, audit records, diagnostics, and operation results provide evidence when something fails.

Updates and fresh installs also share permission and dependency contracts. A security feature that exists only on newly installed servers, or only after a manual command, is not a dependable control.

Security is the agreement between boundaries

SHM reduces operational risk, but it cannot make an on-premises server invulnerable. Server updates, strong credentials, correct DNS, application maintenance, backups, monitoring, and disciplined administration remain necessary.

SHM combines several boundaries that need to agree with one another:

• trusted identity plus role and ownership checks;
• constrained execution and safer defaults;
• layered web and mail controls;
• visible operation results and audit evidence.

Together, these controls provide a more dependable security model than any single setting could provide.