Kernel-Enforced Sandboxing

sysg configures kernel enforcement mechanisms per service: rlimits, capabilities, namespaces, cgroups, seccomp, no_new_privs, and Landlock. All of them are Linux, root, and enforced by the kernel — sysg only configures them.

Limits, capabilities, and namespaces

services:
  worker:
    command: "./worker"
    user: "worker"
    limits:
      nofile: 4096
      cgroup:
        memory_max: "512M"
    capabilities: ["CAP_NET_BIND_SERVICE"]
    isolation:
      network: true

Syscall and filesystem confinement (schema v3)

Under version: "3":

• isolation.landlock: { ro_paths, rw_paths } — a Landlock filesystem sandbox (Linux 5.13+). Paths not listed become inaccessible.
• isolation.seccomp: "baseline-v1" — a frozen, deny-by-default syscall allowlist; unlisted syscalls return EPERM. no_new_privs is set alongside.

version: "3"
services:
  worker:
    command: "./worker"
    isolation:
      seccomp: "baseline-v1"
      landlock:
        ro_paths: ["/usr", "/lib", "/etc/worker"]
        rw_paths: ["/var/lib/worker"]

An unsupported kernel or a malformed policy refuses the service (SG0722/SG0724) rather than running it unprotected. baseline-v1 is frozen; a different or stricter policy will ship as baseline-v2, never as a silent edit.

Keys that do not enforce

isolation.apparmor_profile, isolation.selinux_context, isolation.private_devices, and isolation.private_tmp are accepted by the schema but run the service unenforced. Treat them as documentation, not protection.

Diagnostics

• SG0721 — a security key was accepted but cannot be enforced; the service runs unprotected
• SG0722 — seccomp filter could not be built, compiled, or applied; service refused
• SG0723 — no_new_privs could not be set; service refused
• SG0724 — Landlock requested but the kernel ABI is unavailable or insufficient; service refused
• SG0725 — unknown seccomp profile; the only built-in is baseline-v1
• SG0726 — seccomp is unsupported on this CPU architecture