Browser image admission trusts digests in the installed image directory

Đang mở
  • Có gì không ổn?
#534 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
backend, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
6
Fork
2
Merge trung bình
1 ngày 3 giờ
Pull request đã merge (30 ngày)
42

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của elastos/elastos-runtime

Tất cả issue của elastos/elastos-runtime

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.