Disable guest WebAssembly by default; add an opt-in permission
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- rust, typescript, wasm
- Ambito
- backend-api-design, documentation, security
Direzione di ricerca
Inizia tracciando CreateVmConfig sul wire e il modo in cui le autorizzazioni raggiungono il client TypeScript NodeRuntime/secure-exec e il client Rust. Esamina la documentazione di runtime-platform e il modello di autorizzazioni esistente con negazione predefinita. Il lavoro è completo quando WebAssembly guest è disabilitato per impostazione predefinita, uno scope opt-in funziona con entrambi i client e sono documentati la motivazione di sicurezza e il compromesso del pacchetto npm.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Make guest WebAssembly disabled by default, and add a permission scope users opt into to re-enable it (consistent with our deny-by-default permission posture).
Motivation
Today the guest WebAssembly API is always available in the V8 isolate (runtime-platform docs: "WebAssembly stays available on every tier"). There is currently no way to disable it (no expose_wasm / jitless flag plumbed through the runtime).
WebAssembly grants the guest no additional capability over JavaScript (both are isolate-confined, have no ambient authority, and route all I/O through the kernel), and the classic side-channel vector (Spectre via SharedArrayBuffer + high-resolution timers) is already mitigated by default by timingMitigation: "freeze" (removes SharedArrayBuffer, freezes timers).
The remaining, legitimate concern is V8 JIT/compiler attack surface: the WASM compiler is large and complex, and WASM JIT bugs have historically been used for in-isolate memory-corruption → sandbox escapes. For maximally-untrusted workloads, being able to remove that surface is valuable defense-in-depth. Since we are deny-by-default everywhere else, WASM should follow the same model.
Proposed design
- Add a permission scope, e.g.
permissions: { webAssembly: "allow" | "deny" }, deny by default. - When denied, the guest's
WebAssemblyglobal is unavailable (and ideally the isolate runs without the WASM compiler / jitless where feasible) so the JIT attack surface is actually removed, not just the global hidden. - Plumb through
CreateVmConfigon the wire and expose on both the TypeScript client (NodeRuntime/secure-exec) and the Rust client (per the wire/client-parity rule). - Update the
runtime-platformdocs: note WASM is off by default for hardening, how to opt in, and the security rationale (no extra capability; side-channels already mitigated; this reduces JIT attack surface).
Tradeoff to weigh during design
Some real npm packages ship WASM internally (certain crypto/compression/image/parsing libs). Deny-by-default will break those unless the user opts in, so the opt-in must be easy and clearly documented. (If default-off proves too disruptive in practice, the fallback is default-on with an easy opt-out, but the issue as filed requests default-off + opt-in.)
Notes
- Distinct from the WASI command runtime that runs
sh/coreutils (those are separate WASM binaries the sidecar runs); this is specifically the guest'sWebAssemblyglobal.
- Lingua principale
- TypeScript
- Stelle
- 1k
- Fork
- 54
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di rivet-dev/dynamic-apps
-
Build cache ignores maxResponseBytes, potentially reusing an outdated response limitForse già presa @Utkarshpandey0001 l’ha presa 20 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 78/100
rivet-dev/dynamic-apps#297 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
rivet-dev/dynamic-apps#280 · 2 commenti ·
-
Make agentOS runtime classifier content-based (match Linux exec semantics), not extension-basedForse già presa @mittal-parth l’ha presa 25 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
rivet-dev/dynamic-apps#275 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
rivet-dev/dynamic-apps#272 ·
-
Treat the WASM/WASI build target as cfg(unix) so filesystem tools need no per-tool mode-bit patchesAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
rivet-dev/dynamic-apps#271 ·
Tutte le issue di rivet-dev/dynamic-apps
Issue simili
-
[Docs] README: FAQ setup command, IDA in the intro, Node badgeForse già presa @akram1089 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
morluto/rea#1353 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[Feature]: [P3] engine-rs: the package source hash should ignore line endings and untracked filesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
maniator/verticopolis#880 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
siyuan-note/siyuan#20353 ·
I maintainer di solito rispondono entro 1 giorno
-
afk-ok area:data-quality importer size:S
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
enorm-labs/event-junkie#3027 ·
I maintainer di solito rispondono entro 1 giorno