Philpax

https://fosdem.org/2026/schedule/event/KSK9RB-capability-based-redox-os/

• Definitions:
  • security: minimise risk to data/services if process is hijacked
  • sandboxing: restrict program accessibility through separate environment
  • allowlist
  • ambient authority
• Capability: unforgeable token of authority
  • Refers to a resource, as well as access rights for that resource
  • Similar to a file descriptor
  • Permitted actions (r/w), but fine-grained (get owner, change settings)
  • Cannot be forged
  • FDs are implemented as capabilities
• Capability-based security in other OSes
  • FreeBSD Capsicum
  • Linux
  • seL4
• Goals
  • CBS main mechanism for services/resources in Redox
  • Infrastructure for FDs
  • Capability APIs compatible with existing capability solutions
  • Sandboxing wit hchroot / Redox Contain
  • Capabilities eventually used for other things, like shmem / processes and threads / etc
• Current work
  • Converting named resources
  • FD infrastructure implemented
  • Doing more general caps later
• Schemes
  • Identifies services/drivers
  • All resources are accessed through scheme paths
  • Usually in URI format, but to improve compatibility, moving to slash-paths
• Before caps, file access:
  • Done through ambient authority
  • Namespaces do not protect read/write, only open
  • Scheme API converts requests to file operations
• openat
  • By default, open using a relative path
  • Just a convenience when unrestricted
  • But if you limit access to a folder, it's sandboxed
• Namespace management is in userspace
  • nsmgr mediates all namespace fd requests
  • Applications only operate relative to their namespace_fd
• Capabilities in RedoxOS
  • Resources and files are not distinct in RedoxO; everything is a resource, and every handle is a capability
  • Two types of capabilities:
    • Direct capabilities:
      • Resource capability: points to specific resources
      • Permission capability: points to an abstract right
    • Indirect capabilities:
      • Passed as an argument to another operation on another capability; used as tokens
• File descriptors as capability handles
  • File Descriptor (user space): integer index for references
  • File Description (kernel space): actual object storing the right
  • The user cannot forge these, so possessing it is source of authority
• Granting a capability
  • Can be inherited from a parent
  • Can be sent between programs
  • Can grant a capability to a less-privileged program via Unix domain socket or Redox-native capability forwarding
  • Capability provides a grant, so no UID checking is necessary as long as the capability is open
• Sandboxing:
  • chroot
    • each scheme has a distinct root, and each root can be changed independently (e.g. file can be sandboxed independently from ip)
  • Redox-specific tooling
• To expand your scope in RedoxOS, you need an outside agent with that capability to grant you that
• Future work:
  • Rework FDs to work atop general caps
  • Fine-grained right bits for cap representation in kernel
  • Memory-sharing with caps
  • Borrow more from FreeBSD Capsicum in general
  • Provide WASI/cap-std Rust library