Repository navigation
Required: Isolation as promised #173
Description
ElastOS promises that the Runtime is the only authority and that Home and every app run on top of it in a sandbox. A hacked Home must reach only Home: never the Runtime's internals, localhost or the host. Everything that crosses goes through the Runtime (Carrier for off-box traffic) with explicit approvals and capability tokens. Home's only special power is delegation: launching and stopping capsules on user action and brokering capsule-to-capsule calls. Nothing needs root at run time; if the installer needs root once (for example to install a system service), it says so and asks first.
A code review on 1 October found that the code at that time did not keep this promise (historical baseline). Home and all apps are web pages on the Runtime's origin; Home can mint and use every app's token; untrusted content shares Home's origin; a web terminal starts a host process; providers run unconfined and receive the device key; the Linux Browser engine needs passwordless sudo; the gateway trusts null and any loopback origin; and the docs claim more isolation than exists. That was the pre-release plan. Anders later moved S1/S2 after 0.8.0 and kept the stated S0 scope in the 12 October decision. The Browser provider enforcement and B14 criteria below retain their full scope.
Target
- T1 Untrusted content never shares an origin with Home or apps.
- T2 The Home GUI is a capsule in an opaque sandbox whose only channel is the Runtime, with only a delegation capability.
- T3 The Runtime mints each app's capability into the sandbox it mounts: scoped, short-lived, revocable, ended by a real stop.
- T4 Every approval is shown by a Runtime-owned surface that Home and apps cannot script, and the passkey signs exactly what is shown.
- T5 The Runtime runs without any root path at run time (no sudo, setuid or file capabilities); each provider runs confined to what its manifest declares; keys stay in the Runtime or in their key providers (the did provider for the device key, the wallet provider for wallet keys). The Runtime's local control listener and attach secret are reachable only by the Runtime account's own tools, not by providers.
- T6 The front door accepts only expected origins and hosts, nothing sensitive works without sign-in, and nothing listens beyond this device unless the owner turns it on.
- T7 Docs, manifests, website and release notes state exactly what is isolated.
- T8 Carrier peers (remote Homes, rooms, contacts, service offers) are held to the same rules.
- T9 Installs and updates accept only the signed release set, and the release key is kept off public servers and away from candidate code.
- T10 A user's keys and private data are readable only by that user: never by the operator of a hosted Home, and not by other software or users on a self-hosted device while Home is locked.
Threat model
- In scope: script in the Home GUI, in any app frame, in a CID or site page, or in a same-origin document other than the host; a foreign web origin, another localhost port and DNS rebinding; a local process with no session; a hostile Carrier peer; a compromised native provider; an internet guest on the public seed; a tampered installer or release on the seed; a device on the same network; an app, provider, peer or guest that tries to exhaust memory, disk or CPU; hostile text or model output passed through the Assistant; a stolen copy of the old maintainer key; the operator of a hosted Home, including root on the seed; other software or OS users on a self-hosted device while Home is locked.
- Out of scope, stated in the docs: code running as the user or as root on a self-hosted device while Home is unlocked, the user's browser and its extensions, physical access, a stolen Recovery Kit or passkey authenticator, recovery from a stolen device or profile key (it means a new identity), the development process itself (it relies on Irzhy's review).
Steps
- S0: Serve CID and user content in an opaque sandbox, never as Home #168 untrusted content sandbox; Web terminal only in developer mode, off by default and in public mode #169 web terminal off by default; Gateway: refuse null and foreign loopback origins, check Host, protect Carrier bootstrap #167 front door (origins, Host, Carrier bootstrap, app CSP, Documents Markdown escaping); State actual isolation in docs, manifests and release notes #170 honest docs, manifests and release notes; Seed: run the seed service under its own account without sudo or Docker #174 seed under its own account, and the public demo reopens only after S0 is deployed and tested; Replace the maintainer release key and keep signing off the public server #186 new maintainer key, signing off the seed, and only the signed release set served.
- S1: Linux Browser launcher must not need passwordless sudo #165 root-free Browser networking; Serve only hash-verified capsule assets #171 hash-verified capsule assets; Confine every native provider and stop handing it the device key #166 provider confinement and keys, fail-closed per platform; Installer: run the Runtime as a limited service on Linux and macOS #183 the Runtime as a limited service that exposes nothing to the network unless the owner turns it on.
- S2, before 0.8.0: Design: Home GUI as a sandboxed capsule with a Runtime-owned host #172 design, then Home: split into a Runtime-owned host and a sandboxed Home GUI capsule #176 Runtime-owned host and sandboxed Home GUI, Runtime places scoped, short-lived app capabilities into each frame, with real stop #177 per-frame capabilities with real stop, Runtime-owned approval surface for every approval, with the passkey bound to what is shown #178 Runtime-owned approval surface, Carrier peers follow the same capability rules as local apps #179 Carrier peer rules, Hacked-Home regression suite in CI #180 hacked-Home regression suite in CI.
- S3, after 0.8.0: Bus v2: resident WASM components with UI channels #181 Bus v2 resident WASM components; VM capsules beyond the Browser engine #182 VM capsules beyond the Browser engine; User keys and private data that the host cannot read #209 user keys and private data that the host cannot read (before hosted accounts hold real value).
0.8.0 vs after 0.8.0: 0.8.0 requires S0-S2. Key and private-data protection from the host (T10, #209, milestone After 0.8.0) is S3 and is scheduled after 0.8.0, per the existing step: “S3, after 0.8.0: ... #209 user keys and private data that the host cannot read (before hosted accounts hold real value).”
Every Done means names its test or proof.
The public demo is paused since 1 October; #174 decides when it reopens.
Until S2 is done, no PR adds a public route, an approval type, or an app or provider capability unless its issue records approval under this plan.
Chat already has the contact-request approval in #86 and the bounded participant-history approval in #139. Their implementations retain destination/conversation authority and refused-case tests. #264 records its own approval if leaving Community needs another route or capability. These links preserve the current S0 through S2 and later S3 scope.
Every S0-S2 change needs a regression test for the refused case. Merge rule (Anders, 2 October): a PR merges into develop when all checks are green and an independent adversarial review from a different model family than its author has passed (Codex authors use elastos-pr-review, a Claude review; Claude authors get a Codex review). Changes to the gateway, page security headers or frames also pass the installed Home journey (#153) before merge. Irzhy reviews merged security changes afterwards and owns the isolation design (#172), the threat model and the attack suite (#180); main, tags and releases stay with Anders. Third-party executable capsules stay unavailable.
Every S0-S2 change needs Irzhy's review, so these PRs go to the front of his queue.
Done means
- S0 (except Seed: run the seed service under its own account without sudo or Docker #174, moved to 0.8.1) plus honest docs (State actual isolation in docs, manifests and release notes #170); S1-S2 in 0.8.1. S0 is Serve CID and user content in an opaque sandbox, never as Home #168 untrusted content sandbox, Web terminal only in developer mode, off by default and in public mode #169 web terminal off by default, Gateway: refuse null and foreign loopback origins, check Host, protect Carrier bootstrap #167 front door, State actual isolation in docs, manifests and release notes #170 honest docs, manifests and release notes, Replace the maintainer release key and keep signing off the public server #186 new maintainer key with signing off the seed. The public demo reopens only after Seed: run the seed service under its own account without sudo or Docker #174.
- Moved to 0.8.1: S1: Linux Browser launcher must not need passwordless sudo #165 root-free Browser networking, Serve only hash-verified capsule assets #171 hash-verified capsule assets, Confine every native provider and stop handing it the device key #166 provider confinement and keys (fail-closed per platform), Installer: run the Runtime as a limited service on Linux and macOS #183 the Runtime as a limited service that exposes nothing to the network unless the owner turns it on.
- Moved to 0.8.1: S2: Design: Home GUI as a sandboxed capsule with a Runtime-owned host #172 design, Home: split into a Runtime-owned host and a sandboxed Home GUI capsule #176 Runtime-owned host and sandboxed Home GUI, Runtime places scoped, short-lived app capabilities into each frame, with real stop #177 per-frame capabilities with real stop, Runtime-owned approval surface for every approval, with the passkey bound to what is shown #178 Runtime-owned approval surface, Carrier peers follow the same capability rules as local apps #179 Carrier peer rules, Hacked-Home regression suite in CI #180 hacked-Home regression suite in CI.
- Every S0-S2 change has a regression test for the refused case and passed independent cross-family review, plus Irzhy's security review.
- The Browser authority acceptance contribution below passes on the release candidate.
Browser authority acceptance contribution (#283, B14)
Runtime enforces the Browser owner's grants for Engine actions, inspection and selected Exit connections. Source work can begin from the existing capability/owner contracts; this Browser contribution retains the applicable platform and required human-review gates.
- Issuing Runtime blocks new dispatch immediately on revocation. Under the normal network profile, reachable Engine and Exit providers acknowledge/enforce within 2 seconds, including already active browser/network effects.
- During partition, each enforcing provider's renewable authority lease expires within at most 30 seconds. Suspend, clock change and process restart preserve expiry and require fresh authority before continuation.
- Replay, cross-principal page/profile substitution, unauthorized inspection, altered providers, raw debug access and Net/storage bypass attempts are refused for both human and agent paths.
- Trusted approval is supplied by Runtime-owned approval surface for every approval, with the passkey bound to what is shown #178's Runtime-owned surface. Website text and ordinary app content cannot grant operator or Wallet authority; the full mission verifies real approvals and resulting effects.
- The Browser VM and inner Chromium boundaries are described accurately. Test inner sandbox enablement or record a named scoped exception with owner, compensating boundary, review and release decision. The current --no-sandbox argument alone is not a proof of the VM boundary.
- State actual isolation in docs, manifests and release notes #170/Serve only hash-verified capsule assets #171/Confine every native provider and stop handing it the device key #166/Runtime places scoped, short-lived app capabilities into each frame, with real stop #177/Runtime-owned approval surface for every approval, with the passkey bound to what is shown #178 outputs retain their own ownership; combined Browser proof verifies admitted artifacts, applicable confinement, real stop and approval binding.
- Default Browser diagnostics exclude typed secrets, credentials, cookies and page snapshots. Authorized traces have bounds, retention and deletion.
The current remote supervisor's 5-second check and 50-second stale heartbeat differ from B14's required bounds. Provider-side measured fault tests, rather than timer edits alone, establish acceptance. irzhywau's authority/isolation/approval review remains separate from independent agent review. Preserve #173's approved threat model and its before/after-release scope; this contribution does not move unrelated later platform work into the first local Browser milestone.
Browser plan reconciliation — 2026-10-08
The executable consumers are #289 session bounds, #290 operator actions, #291 remote Engine/Exit, #292 profiles and #293 qualification. Keep provider-side authority as this issue's Browser contribution: immediate issuing-Runtime refusal, reachable enforcement within 2 seconds and partition lease expiry within 30 seconds, with suspend/clock/restart tests. #131's exact pending lifetime and settlement retain resource barriers. Browser source milestones consume accepted authority outputs; final isolation/approval/review gates and the existing S0–S3 schedule remain unchanged.
Local AI plan reconciliation — 2026-10-08
#99 supplies the Local AI confinement contribution; #98/#100/#101 supply resource/lifecycle/retry proof, and #103 binds the installed target matrix. The existing #166 shared provider rights and #180 hostile-model-output tests remain required. Runtime authorizes each effect proposed by a model under the same principal/session rules as a human action.
Activity
andersalm commentedon Oct 1, 2026
The public demo on https://elastos.elacitylabs.com is paused since 1 October, 19:58 UTC, until the isolation fixes in #173 ship. The web server answers 503 with a short notice for /home/, /apps/, /api/, /s/ and /content/. The website, install.sh, /release-head.json, /release.json, /artifacts/, the publisher Carrier bootstrap under /.well-known/ and /ipfs/ downloads stay available; /ipfs/ responses carry a sandbox Content-Security-Policy. The accounts are kept. Undo: restore the saved web-server config and reload.
andersalm commentedon Oct 1, 2026
Local AI session owns #97's 2 October bounded Jetson proof and #150 / draft PR #153's Mac CI fixture repair.
This work keeps the existing public routes, approvals and app/provider powers; authority changes require recorded approval here.
The isolation session retains the gateway front door and
provider/bridge.rs; this session will coordinate any dependency through issues.The isolation session has priority for the Mac's single heavy build slot; CI and light source checks can proceed in parallel.
Required reviews remain with Irzhy, with two independent review rounds and refused-case tests for corrections.
andersalm commentedon Oct 1, 2026
Session scope: gateway front door and provider launcher confinement; active task #168, base/target develop at c9205a7; PR pending.
Approved sequence, one active task: #168 → #169 → #167 → #170 → #165 → #171 → #184 → combined #166/#99 → #183; issue-specific base instructions take precedence.
After #168/#169 merge, record the design note in #172 for Irzhy and Sasha; #176 through #180 begin after their acceptance.
Every PR proves the refused case, has at most two review rounds, requests irzhywau after green checks, and merges after his approval; Anders approves #170 public correction.
Authority freeze lasts through S2; each exception needs approval in its issue under #173. Seed, main, tags and releases stay outside this session; local builds are serial and free disk stays above 15%.
andersalm commentedon Oct 1, 2026
The active order is #188 CI repair and review, with #169 in a separate worktree while CI runs.
The #188 hang is understood; #167 starts from its corrected branch and waits for #188 integration before merge, followed by #170.
#186 follows #170 for code only: separate signing tool, publish-release signer, source re-trust, main-tag release gate, pinned Actions and signed served files.
Anders retains key custody and person-run proofs; #160 integration gates overlapping update.rs, install.sh and ci.yml work, and its branch stays with its owner.
The consolidated 18-issue plan, authority freeze, refused-case tests and Irzhy approval before merge remain the acceptance contract.
andersalm commentedon Oct 1, 2026
#150 / draft PR #153 now needs a Mac reproduction of installed candidate cd00623 for a cold reply backend_timeout; the current reply deadline stays fixed.
The Mac currently has 81 GiB free and the process inventory shows the heavy build slot idle.
Local AI requests the next free slot for an exact-candidate source-home build; isolation retains priority, so please record any current reservation or handoff here.
Gateway front-door files and provider/bridge.rs remain owned by isolation; any finding on those paths will be recorded here for that session.
The Linux x86 apt timeout is recorded in #150 and only its cancelled CI job was rerun; #97's Jetson attempt stays with its 2 October heartbeat.
andersalm commentedon Oct 1, 2026
The shared Mac build ledger records isolation #167's slot as finished at 22:39 UTC, and the compiler process inventory is empty.
#150 will claim that released lease for the exact cd00623 isolated source-home build, with a 15% free-disk stop guard and shared dependency cache.
The build writes only this session's source outputs and new test Home; existing Homes and isolation source files stay with their owners.
Isolation keeps priority for its next reservation; this session will release the lease when installation finishes and record the handoff here.
Cold reply diagnosis retains the 120-second provider deadline and records engine, health and reply timing before any cause correction.
andersalm commentedon Oct 1, 2026
#150's local Playwright 1.59.1 setup reproduced the Node 26 extraction stall after its 92 MiB headless-shell download reached 100%.
The same pinned package and browser revision installed successfully with a local Node 20 setup process; the installed journey will still run with Node 26 like CI.
Only that owned stalled installer and its child were stopped; the replacement added the missing test browser shell.
This is setup evidence for the #188 diagnosis, separate from #153's Rust model backend_timeout; the exact Mac source-home build remains under the shared lease.
Current free disk is above 16%; the 15% stop guard and isolation build priority remain in effect.
andersalm commentedon Oct 1, 2026
#150's exact cd00623 source-home installation completed; the shared heavy build lease is released for isolation's next build.
The new Mac fixture has its own Runtime, providers, capsules, verified pinned engine and installation receipt.
Existing Homes and isolation source files remain under their owners; local free disk remains above the guarded 15% floor.
Next is the light installed cold reply measurement with the existing provider deadline, outside the build slot.
Any launcher or front-door finding will be sent here for isolation ownership.
andersalm commentedon Oct 1, 2026
Isolation #167 released the shared heavy build lease at 23:17 UTC; the compiler inventory is empty and free disk is above 16%.
#150 will use that released lease for narrow model-provider timing tests with the 15% stop guard, then release it for isolation.
The original installed wrapper left one detached Browser helper in the disposable Home; its saved identity was checked and the owned helper was stopped.
This cleanup finding stays with the launcher owner for coordination; #150 edits only model-provider timing and safe CI receipts.
The exact baseline cold reply passed in 10.355 seconds, so the 120-second provider deadline remains fixed while GitHub Mac stage evidence is added.
andersalm commentedon Oct 1, 2026
#150 released the shared Mac build lease after the narrow timing verification.
All 16 local engine lifecycle/health tests and 12 local text tests passed serially; the first parallel run had two fake-engine startup timing failures.
Isolation retains priority for its next build; #150 will use a later released lease for the reviewed diagnostic candidate installation.
The production reply deadline stays at 120 seconds and installed proof remains separate from source checks.
Gateway front-door files and provider/bridge.rs remain with isolation.
andersalm commentedon Oct 1, 2026
#150 pushed reviewed diagnostic candidate 0f2211d and started exact-source CI; the provider reply deadline remains 120 seconds.
Isolation released its latest #169 Mac lease at 23:28 UTC, and #150 will use the next free lease for a fresh candidate installation under the 15% disk guard.
The installation copies only verified immutable inputs into a new disposable Home and writes this session’s own final outputs.
The earlier exact cd00623 fixture remains retained with all owned processes stopped; existing Homes and private authority stay intact.
The lease will be released at installation completion for isolation’s next build.
andersalm commentedon Oct 1, 2026
#150’s exact 0f2211d Mac installation and installed model-provider verification passed; the shared heavy build lease is released for isolation.
The fresh fixture binds the reviewed commit/tree and verifies copied engine/model inputs, built/installed Runtime parity and provider manifest hashes.
Pinned-input verification and disposable package preparation passed; the light installed journey is now running outside the build lease.
The controller tracks original process birth identities and preserves any later isolation lease owner during cleanup.
The provider reply deadline remains 120 seconds; gateway front-door files and provider/bridge.rs stay with isolation.
andersalm commentedon Oct 2, 2026
#150 / draft PR #153 passed all source and installed Mac/Linux checks at f6c66c5; #98 / draft PR #136 now continues its separate Linux resource proof.
Isolation #186 released the shared Mac lease at02:43 UTC; the compiler inventory is empty and free disk is above15%.
Local AI will use the released lease for narrow model-provider unit/process tests from its own continuation worktree, sharing dependency artifacts and keeping own final outputs.
The15% stop guard stays active; isolation retains priority for its next reservation and the lease will be released when these checks finish.
Gateway front-door files and provider/bridge.rs retain isolation ownership; this continuation changes resource-test fixtures and private CI proof only.
andersalm commentedon Oct 2, 2026
#98 released its shared Mac build lease after the first narrow provider test build; isolation #170 now owns the next lease.
That build found two retained queue fixtures missing the added optional timing argument; the continuation source now supplies it explicitly.
All four basic gates passed; the corrected provider tests will run after isolation releases its lease and the15% disk guard permits them.
CI harness source work and light refused-case checks continue while isolation has priority.
Gateway front-door files and provider/bridge.rs retain isolation ownership; existing Homes and keys stay intact.
andersalm commentedon Oct 2, 2026
#98 released the shared Mac build lease after its corrected provider checks passed:249 unit tests and10 process tests, with installed lifecycle still reserved for Linux CI.
The checks cover the preserved admission, queue/cancellation, account lease and engine cleanup paths; all four basic gates also passed.
Free disk remained above15% under the active stop guard, and this session's final outputs stay in its own worktree.
Isolation retains priority for its next build; the remaining #98 harness work and independent reviews use light checks.
Gateway front-door files and provider/bridge.rs retain isolation ownership; fresh fixture evidence and Linux resource qualification remain separate from the accepted #150 ordinary reply.
andersalm commentedon Oct 2, 2026
This session merged its own #155, #142 and #144 after posted Claude PASS; #142’s four Mac confinement tests passed.
PR #148’s End ordering change now conflicts with develop in
elastos/crates/elastos-server/src/api/mod.rs; isolation retains that front-door file.Please provide the owned resolution through #148 or this issue; this session will integrate it normally and preserve the reviewed End behavior.
#148 source
20076de5b7570d5688670d48d32146abd3c015eb, current develop93a7284db358a9099c7af407dd7152a6c5a3decb; CI36864014484 and the posted operator PASS remain qualified inputs.The Carrier fix, normal ARM engine input and Mac reply timings continue in this session’s own worktrees; the12:00UTC Jetson slot remains first.
andersalm commentedon Oct 2, 2026
PR #153 CI36964468702 and PR #136 CI36964466444 remain blocked before model admission: the real signed-in Home reaches an empty Marketplace; exact receipts and media bind tasks
aa9a2bda/77dd1c98and their tested trees.#167 now assigns its dispatch-only CI job the existing #153 installed journey, with pinned harness provenance and owned-process cleanup: prove PR #202 on its exact head before merge, then on the exact merged develop commit.
Read-only integration previews at
aa9a2bdab03472cf7100af4833e846d0667a1b70: owner #202 head3bceced34ddb0b79139becc3e933745556349b55merges cleanly (preview tree4bd1be2227d5073c8eda376e092d723efb4d920d); develop829a24adconflicts in this session's.github/workflows/ci.ymlandscripts/ci-release-policy-test.py.Isolation owns the CSP and foreign-frame authority boundary. Please hand off the accepted #202 candidate and installed proof here; this session will then integrate normally, resolve its two CI conflicts, preserve the 120s deadline / eight-token bound, and obtain three Mac timings plus #98's separate lifecycle proof.
PR #133 is merged and its normal develop engine/cache proof is green. The separate heartbeat retains the sole 12:00UTC Jetson slot with its prepared candidate, fixed guard, 30-minute limit and cleanup.
andersalm commentedon Oct 2, 2026
Paused on 2 October (Anders): ElastOS focuses on one end-user goal, install.sh on a Mac and an update to the next version (#89). After today's wrap-up, isolation work pauses except #186 (new release key and signer), which that goal needs. #202 finishes only after its installed check; #199 is parked.
andersalm commentedon Oct 2, 2026
#167 closed after PR202, its green CI, Codex PASS and the exact merged-develop installed journey proved its Done means. The old isolation queue remains paused under #89.
andersalm commentedon Oct 3, 2026
Anders’s 3 October ownership decision assigns the #110 Home System update journey to this session, including gateway-side temporary Carrier cleanup. The initial action uses POST on the existing System summary resource and the existing owner/passkey path; its canonical intent binds source, channel, signer, versions and signed head/release CIDs. The release session reviews the gateway candidate.
The #110 contract keeps ordinary checks read-only and release-changing authority with the admin principal and fresh System passkey effect. This implements the existing #89 first goal; broader approval types and provider capabilities retain their own scope decisions.
andersalm commentedon Oct 3, 2026
The direct 3 October operator instruction assigns this session the normal Home System update journey and gateway-side Carrier cleanup: “Start with #109 … then the Home System screen update in #110.” Draft PR229 records the concrete first-goal scope: POST
applyon the existing/api/apps/system/summaryresource, with the existing owner/passkey approval type and exact signed source/channel/publisher/versions/head/release intent.Read-only checks retain viewer scope; release-changing authority requires the admin principal, System launch binding, fresh passkey effect and durable exact replay ownership. Release reviews the gateway candidate. Broader routes, approval types and provider/app authority remain their own decisions; the draft merge waits for the installed journey.
[-]0.8.0: Isolation as promised[/-][+]Required: Isolation as promised[/+]andersalm commentedon Oct 13, 2026
Postponed to 0.8.1: isolation S1/S2 is not a 0.8.0 blocker (Anders, 12 Oct); #170 states the real isolation. S1 and S2 items moved; S0 stays (without #174).
andersalm commentedon Oct 15, 2026
Moved to After 0.8.0 per Anders's decision 6136835874 (S1/S2 do not block 0.8.0; planned for 0.8.1). S0 (#167, #168, #169) is closed; the 0.8.0 part is #93 gate 2 (#170 correction, #186).
andersalm commentedon Oct 20, 2026
Three Shell follow-ups for after 0.8.0 are recorded privately under SECURITY.md. They become tasks in this issue after 0.8.0 ships. Source: Sash's review of the Shell agent, checked against the 0.8.0 candidate on 20 Oct.
irzhywau commentedon Oct 30, 2026
Heads-up for #173 approval: the #388 protected-content work adds one owner/passkey route (
DELETE /api/apps/custody/local-node, step-upcustody.local_node.remove) and a Creator method to list/resume unfinished mints (unfinished_protections,runtime_custody_resume); each is declared in one place.Planned next: cross-Home custody, so a buyer on any Home gets the content key from the item's own custody pool; this will add routes/capabilities, which we'll list here for approval before the PR.
No new approval types for the DASH media format; its wire changes are optional fields on existing provider calls.