1.7 KiB
1.7 KiB
title, description, weight
| title | description | weight |
|---|---|---|
| Security & privilege isolation | Security measures, privilege isolation, and project-level sandboxing. | 20 |
Security in Root is achieved through strict privilege isolation and project-level "sandboxing" to mitigate the impact of service compromises.
The "No-Root" principle
Running applications as root inside containers is a significant security risk. The framework enforces isolation via the tiers/useradd and tiers/chown actions.
Project-specific users
Every project (e.g., traefik, synapse) is assigned a dedicated system user on the host.
- Isolation: If a container is compromised, the attacker only gains the privileges of that specific low-privileged user.
- Filesystem safety: Projects can only read/write to their own directories within the Tiers.
Docker socket protection
Direct access to /var/run/docker.sock is equivalent to root access on the host. To prevent services from abusing this access, the framework utilizes a Socket Proxy.
- Restricted API: The proxy filters Docker API calls, allowing only necessary operations (e.g.,
GET containers) and blocking dangerous ones (e.g.,POST containers/create).
Network hardening
Root uses configure/ufw to implement a "Default Deny" policy.
- Internal routing: Services communicate over a dedicated
root-directbridge network. - TProxy integration: Outgoing traffic is routed through Xray for enclave-like isolation and granular routing rules.
See also: