The daemon control socket (packages/kernel-cli/src/daemon/rpc-socket-server.ts) has no authentication. Authorization is entirely filesystem permissions — and neither the socket nor ~/.ocap is created with an explicit mode (daemon-entry.ts:41, rpc-socket-server.ts:274), so the effective permissions depend on the ambient umask.
The handler set includes executeDBQuery (rpc-socket-server.ts:43-46), which runs arbitrary SQL against kernel state, alongside reset, clearState, terminateAllVats, and revoke.
executeDBQuery is very useful for development and debugging. It should not be reachable in a deployed configuration.
Proposed:
- Create the runtime directory
0o700 and the socket 0o600 explicitly rather than relying on umask.
- Remove
executeDBQuery from the default handler set; expose it only behind an explicit development flag.
- Consider whether the remaining destructive methods (
clearState, reset, terminateAllVats) warrant the same treatment.
- Document the trust model of the socket, since "local access == full control of the kernel" is a reasonable design choice but should be a stated one.
The daemon control socket (
packages/kernel-cli/src/daemon/rpc-socket-server.ts) has no authentication. Authorization is entirely filesystem permissions — and neither the socket nor~/.ocapis created with an explicit mode (daemon-entry.ts:41,rpc-socket-server.ts:274), so the effective permissions depend on the ambient umask.The handler set includes
executeDBQuery(rpc-socket-server.ts:43-46), which runs arbitrary SQL against kernel state, alongsidereset,clearState,terminateAllVats, andrevoke.executeDBQueryis very useful for development and debugging. It should not be reachable in a deployed configuration.Proposed:
0o700and the socket0o600explicitly rather than relying on umask.executeDBQueryfrom the default handler set; expose it only behind an explicit development flag.clearState,reset,terminateAllVats) warrant the same treatment.