Cheri Seal

Questions

  • How can Java/C++ benefit from CHERI’s sealed caps?
  • Can Rust ownership benefit from CHERI’s sealed caps?

Why explicit unseal/ccall

(ISAv71 Ch 8.18): Unseal is an explicit operation. In CHERI, it requires explicit operation to convert an undereferenceable object into a pointer. CUnseal or CCall.

An alternative architecture would have been one with implicit* unsealing, where a sealed capability could be dereferenced without explicitly unsealing it first, provided that the subsystem attempting the dereference had some kind of ambient authority that permitted it to dereference sealed capabilities of that type. This ambient authority could have taken the form of a protection ring or the otype field of PCC.

A disadvantage of an implicit unseal approach such as the one outlined above is that it is potentially vulnerable to the Confused deputy problem2: the attacker calls a protected subsystem, passing a sealed capability in a parameter that the called subsystem expects to be unsealed. If unsealing is implicit, the protected subsystem can be tricked by the attacker into using its privileges to read or write to memory to which the attacker does not have access.

LLM: how to solve? how about OO constraint? Limit the interfaces? Constrain the parameters?

The disadvantage of the CHERI choice is that protected subsystems need to be careful not to leak capabilities that they have unsealed, for example, by leaving them on the stack when they return to their caller. In an architecture with “implicit unseal”, protected subsystems would just need to delete their ambient authority for the type before returning, and would not need to explicity clean up all the unsealed capabilities that they had created.

Sealed Capabilities

Reference: ISAv8

Two types:

  • Sealed pairs:

    • Primarily designed to support the linking of a pair of code and data capabilities for use together during domain transition;
    • CInvoke, a jump-like instruction, allows the two sealed capabilities to be atomatically unsealed as control flow transfers to the code pointed to by the code capability, if their object types match;
    • Can be used to implement controlled privilege escalation for the purposes of domain transition;
    • Sealed capabilities sharing a common object type are the foundation for building the CheriBSD object-capability model supporting in-address-space compartmentalization.
  • Sealed entry capabilities:

    • a single sealed code capability;
    • Can be jumped to, leading to an atomic unsealing and control-flow transfer;
    • to date has primarily been used to strength control-flow robustness within a single protection domain by preventing the undesired manipulation and use of code pointers;
    • Jump-and-link instructions acting on sealed entry capabilities also generate a sealed return capability;
    • Can also be used to implement domain transition with privilege escalation.

Usages:

  • CHERI Domain isolation (in-address-space compartmentalization);
  • Protect code pointers;
  • Representing other sorts of delegated rights (non-hardware-defined);
  • Ensuring that pointers are dereferenced only by suitable code (e.g., in support of language-level memory or type safety).

Capability Object Types

  • Allow multiple sealed capabilities to be indelibly and indivisibly linked;
    • the kernel or language runtime can avoid expensive checks (e.g., via table lookups) to confirm that they are intended to be used together;
    • e.g., CheriBSD object-capability model: code capability + data capability;
  • Updates when a capability undergoes (un)sealing;
    • Sealing: object type is set when a capability is sealed based on a second input capability authorizing use of the type space;
    • the second capability is simply a capability permission authorizing sealing within a range of values specified by the capability’s bounds;
    • Unsealing: a sealed capability is restored to a mutable and dereferenceable state;
    • a suitable capability that have sealed the cap must be held during unsealing;
    • Non-unsealing: sealed capability inspection
    • a suitably privileged component could rederive its unsealed contents by inspecting a sealed capability
      • e.g., kernel?
      • However, authorizing both sealing and unsealing based on type capabilities allows the right to construct encapsulated pointers to be delegated, without requiring recourse to a privileged

  1. CHERI ISAv7. ↩
  2. ↩
Created Sep 23, 2019 // Last Updated Dec 28, 2021

If you could revise
the fundmental principles of
computer system design
to improve security...

... what would you change?