Root stays off the network.

KLYRN runs as two programs. The one that faces the internet has no root access. The one with root access never faces the internet.

The security view: firewall, malware scan and logins, with anything that needs you at the top. — Firewall, malware scan and logins on one page.

Firewall, malware scan and logins on one page.

How the panel is split.

klyrn-web runs as an unprivileged user. It cannot become root, open the database, run a program or make outbound requests. It asks klyrn-core over a Unix socket, and the core decides for itself who is asking.

Browser HTTPS :7443 on the panel's own listener, TLS 1.2+, strict CSP, no inline scripts
rate limits per address and account, server-side session, Origin check + custom request header
klyrn-web user klyrn

Sign-in, sessions, the REST API, live events and the panel's static files. Nothing else.
- become root
- open the database
- execute a program
- use a shell
- make outbound HTTP
- write outside its state directory
Unix socket, mode 0660 root:klyrn, peer credentials checked by the kernel, the actor is re-authorised against core's own records
klyrn-core root, never on the network

A closed registry of typed operations: create site, create database, issue certificate, and so on. Each has its own request type, validator, authoriser and audit entry. No operation takes a command string or an unconstrained path.
argument lists only, never a shell, user paths resolved with openat2 + RESOLVE_BENEATH inside the owning account
nginx, php-fpm, mariadb, systemd, ufw, filesystem one Unix user per hosting account, one PHP-FPM master per account in its own cgroup, one grant per database, sandboxed unit per app

The only path from the internet to root on a KLYRN server. A compromised web tier can do no more than a signed-in administrator, and every one of those actions is in the audit log with actor, address, operation, target and outcome.

A closed list of operations

The core offers typed operations, such as creating a site or issuing a certificate. Each one has a validator, an authoriser and an audit entry. None takes a command string.

Accounts are isolated

Every hosting account is its own Unix user, with a home directory nobody else can list. Each PHP site runs in its own pool, confined to that site. The kernel enforces the account's CPU, memory and process limits.

Signed updates, encrypted backups

Releases are signed with ed25519 and the public key is built into the binary. An update that fails its checks rolls itself back. Backups copied to an S3-compatible bucket are encrypted on the server first.

What is not covered

KLYRN does not filter outbound traffic from hosted sites, and it does not absorb a volumetric attack. Cron jobs run outside an account's CPU and memory limits. Someone with a root shell on the server can do anything.

The security reference

Report a security problem