Browser image admission trusts digests in the installed image directory
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with elastos/crates/elastos-server/src/setup/browser_vm_image.rs, especially verify_installed, and read docs/BROWSER_VM_TARGET.md:113 plus the linked release disposition. Trace where signed component or release data is available and how the verified image is opened before designing a safe admission flow. Done means signed digests reject rewritten image files, Mac and Linux regression coverage proves rejection, launch rechecks file identity, and unsigned Source-Home rows remain clearly marked.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- Rust
- 星标
- 6
- 派生
- 2
- 平均合并
- 1 天 3 小时
- 30 天内合并 PR
- 42
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
elastos/elastos-runtime 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
elastos/elastos-runtime#563 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
elastos/elastos-runtime#508 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
elastos/elastos-runtime#436 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
elastos/elastos-runtime#427 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
elastos/elastos-runtime#405 ·
维护者通常 1 天内回复
查看 elastos/elastos-runtime 的全部 Issue
相似的 Issue
-
Panic on live viewport resize when unstyled elements exist in display: none subtree可能已有人在做 @GoCoder7 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
DioxusLabs/blitz#1488 ·
维护者通常 1 天内回复
-
🏷️ good first issue enhancement
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
S-Needs triage
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
vectordotdev/vrl#2042 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复