Services security

The forbidden intersection is:

  • Running as root, or with CAP_SYS_ADMINand
  • Running in the init PID and mount namespaces, and
  • Running without a Seccomp policy or without an enforcing SELinux domain.

You must avoid the forbidden intersection by having at least one of, preferably more than one of, and ideally all of:

  • Running as a non-root user with no CAP_SYS_ADMIN — User IDs
  • Running in a non-init mount and PID namespace — Namespaces
  • A Seccomp policy OR running with an SELinux policy in an enforcing domain — Seccomp filters or SELinux

You don't normally need both Seccomp and SELinux but for very security-sensitive workloads this can be required.

  • Create a new user for your service (example). Use this README as a guide on choosing and testing the new UID and GID.
  • Optionally, create a new group to control access to a resource and add the new user to that group (example).
  • Use Minijail to run your service as the user (and group) created in the previous steps. In your init script:
    • exec minijail0 -u <user> -g <group> /full/path/to/binary
    • See User IDs.
  • If your service fails, you might need to grant it capabilities. See Capabilities.
  • Use as many namespaces as possible. See Namespaces.
  • Consider reducing the kernel attack surface exposed to your service by using Seccomp filters. See Seccomp filters.
  • Add your sandboxed service to the security.SandboxedServices test.