Repository navigation
Browser image admission trusts digests in the installed image directory #534
Description
Problem
The Browser VM image (rootfs, kernel, initrd) is admitted by comparing the bytes the Runtime hashes against digests in browser-vm-rootfs-manifest.json, a receipt file that sits in the installed image directory next to the image (elastos/crates/elastos-server/src/setup/browser_vm_image.rs, verify_installed). The receipt's own check (.elastos-image-manifest-sha256) and the archive check (.elastos-artifact-sha256 against the component row's archive checksum) are also files in that directory. Nothing in that chain is signed or held outside the Home user's write access, so a process running as the Home user can replace the image bytes and rewrite all four files consistently, and admission accepts the chosen bytes. docs/BROWSER_VM_TARGET.md:113 says adjacent files provide no verification authority.
This is on develop today (Mac VZ since 2.0.0, and Linux ARM on #531). Found by a Claude review of #531 on 5 Nov while checking Codex Root's HOLD (the separate persistent verified-identity record, removed in #531).
Release disposition — 2.0.1, 5 November 2026
No hold for this finding alone under the current host-account-write precondition; reasoning, limits and change conditions. The issue remains open for signed expected digests and regression proof. Privileged helper execution and installed Browser acceptance keep their separate gates.
Done means
- The per-file digests of rootfs, kernel and initrd come from signed release data (the signed component row or release head), not from files in the installed image directory; admission refuses when the hashed bytes differ from the signed digests.
- A regression on Mac and Linux: replace the rootfs bytes and rewrite the receipt and both adjacent hash files consistently; admission refuses.
- The file that was verified is the file the VM opens: identity re-checked (dev, inode, size, mtime, ctime) immediately before the overlay or copy is created, or the verified descriptor is used; a change in between refuses the launch.
- Source-Home setups still work (their unsigned local rows are marked as such and never shown as a signed release).
Related: #406 (privileged setup bound to signed admission), #90, #531.
Activity
andersalm commentedon Nov 5, 2026
Keep this as a separate repair with its own review and tests. Retain it as a dependency of #90 signed-image acceptance, with an explicit release hold/no-hold decision based on the final proof.
Source review confirms that the stable Runtime compares the image with the adjacent build receipt and compares that receipt with another adjacent hash file. This underlying expected-digest gap predates PR #531's persistent cache finding.
Main owns the fix. Bind expected digests to signed release data, keep source-Home provenance explicit, and test consistent replacement of the image and adjacent receipts on both hosts. The latest #531 correction and its startup behavior still await review on a frozen candidate.
fix(#90): keep image hashing in Runtime and bind the launch seed
andersalm commentedon Nov 5, 2026
2.0.1 disposition: NO HOLD for #534 alone, within the reported host-account-write threat model. The default Runtime installation is user-owned too; this finding gives that actor a way to replace guest content, while signed package acquisition and Runtime/guest confinement remain separate boundaries. Prior shipment alone is not the reason for this decision.
The authenticity gap stays open: current local receipts cannot establish publisher-authorized per-file content after that actor rewrites them. Keep the signed-digest repair and both-host replacement regression. This disposition changes if a confined app, remote input, another account or a privileged operation can exploit the same path without prior host-account compromise.
This releases only the #534 hold for #535. Preserve #406’s exact signed-helper execution gate and #90’s signed setup/install/update/profile/Undo, media/manual and human acceptance; production signing and publication retain their existing approvals.