Where exactly does developer responsibility end? Is Every Escape via Endowed Objects a Developer's Fault?

[mingijunggrape]

While using SES, I’ve found it unclear which responsibilities fall on the developer.

Since SES operates on a Trusted Compute Base (TCB),

issues like out-of-memory (OOM) attacks, which arise from the lack of resource management,

are clearly understandable as being the developer’s responsibility.

However, in browser environments, there are cases that feel more ambiguous.

For example, when using harden() on objects like location, it freezes without error, which may lead the developer to believe it is safe to endow location in its hardened state. (assuming that functions like replace() or assign() have been properly handled)

But due to setters, such as href values can still be mutated.

This allows for sandbox escape via schemes like javascript: or data:.

When I asked about this, I was advised to use an "attenuating membrane" as a solution.

This seems to imply that developers are expected to already understand how harden() interacts with host objects like location,

and to proactively handle such cases themselves.

This leads me to a broader concern: In, Node.js if seemingly harmless objects like console are passed to a compartment,

and sandbox escape becomes possible — not through their directly exposed capabilities, like "private" _ prefixed properties,

but through more subtle mechanisms like error object creation or returned objects. Is this still considered entirely the developer’s fault?

Where exactly does developer responsibility end? I would appreciate any clarification or guidance on this boundary.

[kriskowal]

Pardon for the delay.

Is every escape via endowed objects a developer’s fault.

Summarily, yes.

For a longer summary,

For arrangements where there is a host, the host makes a Compartment, endows the Compartment with some hardened API surface including host modules, then executes arbitrary code in the guest compartment, the host is responsible for ensuring that the endowed objects do not provide an avenue for the guest to escape.

• The host must protect itself from reentrant functions offered to the guest, which might give the guest a place to stand to execute arbitrary code while the host has suspended some invariants (as occurs when modifying an internal data structure like a linked list).
• The host is responsible for ensuring that any object that might be shared by the host, guest, or multiple guests, is hardened so that it cannot be used as a communication channel or enable a guest to install alternate implementations of methods. The values returned by hardened APIs must themselves be hardened. A hardened API must be explicit about which endowments convey the ability to communicate through shared mutable state.
• Every party is responsible for treating any object received from another party as potentially hostile, including the possibility that its properties are getters and setters, or the object as a whole is a Proxy, even if it is hardened.
• No party in this arrangement is in a position to defend against an availability attack, like for(;;){}. To defend against that kind of attack, the host must stand in another process and communicate with a hardened facet of itself inside the guest process. For a host that must preserve deterministic behavior, the guest process will need to have a deterministic meter, like the XS JavaScript engine has. For a host that doesn’t rely on determinism, the host can use a timer to detect a non-responsive guest process. The host is responsible for managing failed expectations of multiple guests that attempted to cooperate inside a shared process if one of them stalls the process. It is not practical to ascribe blame, but to inform the guests’ supervisors in other process of the failed attempt at cooperation.
• The host may be responsible for defending guests against attempted timing-side-channel attacks against the host facet in the same process or multiple guests in a shared process. To this end, the best mitigation is for the host to avoid endowing guests with the ability to sense time at any resolution, so no timers endowed, but also no communication to objects in other processes that might inadvertently empower them to construct a clock gadget. CloudFlare uses an exotic ML system to detect these attacks and shut down a worker process. But, the most straight-forward defense is to have the host confine each of its guests in a child process and introduce them to each other through a communication channel like CapTP, which preserves the OCap paradigm between objects in separate processes.

Pardon the hasty response. This is an imprecise first draft of documentation that should be more prominently displayed.

[kriskowal]

Also, the multiple-guests-in-a-shared-process scenario also creates responsibilities for each guest when handling each other’s hardened APIs. A surprising number of interactions enable the other party to execute on your stack, given that they can use proxies. The one-guest-per-process model is a lot easier to manage, falling back to async message passing between object capabilities over CapTP. The ergonomics are mostly the same as same-process at that point. There are corss-process-GC concerns instead.