Process Isolation for Security: Multi-Process Architecture

[jaytaph]

Process Isolation for Security: Multi-Process Architecture

Problem Statement

Currently, all code runs in a single process. This creates a severe security risk:
a vulnerability in any component (image decoder, CSS parser, renderer, JS engine)
can compromise all open tabs and zones.

Attack Scenario

1. Attacker crafts a malicious image and uploads it to a website
2. Gosub renders the image via Cairo/Skia/Vello rasterizer
3. A buffer overflow or integer overflow in the rasterizer is triggered
4. Attacker gains code execution in the browser process
5. Attacker now has access to:
   • DOM of all open tabs
   • All cookies and session tokens across all zones
   • Local storage and session storage of all origins
   • Network requests (can forge requests on behalf of any origin)
   • Window/tab focus and user interaction data

Why This Matters

This violates the fundamental browser security model: data from one origin
should not be accessible to another origin, even if one is compromised.

Solution: Multi-Process Architecture

We will gradually isolate security-critical components into separate processes
with reduced privileges and access control.

Phase 1: Network Isolation

Goal: Prevent SSRF attacks and limit network-related exploits.

Implementation:

• Spawn gosub-net-daemon (network process) at engine startup
• Network process owns all network resources (sockets, connection pooling)
• Renderer/tabs submit fetch requests via IPC (Unix domain socket)
• Network process returns response (headers + body stream)
• Prevents renderer from:
  • Initiating requests to internal IPs (SSRF)
  • Spoofing User-Agent or custom headers
  • Accessing raw sockets

IPC Protocol:

• Format: [u32 length][bincode payload] (length-framed messages)
• Serialization: bincode (compact, fast)
• Message types: FetchRequest, FetchResult

---

Phase 2: Per-Origin Render Isolation

Goal: Isolate renderer from DOM/cookies of other origins. Renderer exploits
cannot leak data across origins.

Implementation:

• Each origin runs in its own renderer child process
• Parent process (engine) coordinates between processes:
• Keeps DOM, styles, cookies, local storage
• Sends render commands (not DOM) to renderer child
  • Receives rasterized tiles back
• Renderer child process:
  • Executes painting pipeline (stages 1–5: layout → paint commands)
  • Rasterizes tiles (stage 6) via Cairo/Skia/Vello
  • Never has access to: cookies, DOM of other origins, network

Architecture:

GosubEngine (parent)
├─ Zone A (origin:example.com)
│  ├─ Tab 1, Tab 2
│  └─ Renderer Child Process A (low privileges)
│     ├─ Stage 6: Rasterize tiles
│     └─ (Cannot access DOM, cookies, other zones)
├─ Zone B (origin:attacker.com)
│  └─ Renderer Child Process B (separate, isolated)
└─ Network Process (Phase 1)

IPC Protocol:

• Parent → Child: RenderRequest (viewport, paint commands, textures)
• Child → Parent: RenderResult (rasterized tiles)
• Format: Same as Phase 1 (bincode length-framed)

Data Transferred (per frame):

• Paint commands: ~10–50 KB
• Textures (images): ~1–2 MB
• Total: ~2 MB/frame at 60 FPS (~120 MB/s over Unix socket, acceptable)

Note: Both CPU (Cairo/Skia) and GPU (Vello) backends run in the same renderer
child process with the same isolation level. Backend choice is not a security
discriminator.

---

Phase 3: GPU Process

Goal: Isolate GPU driver bugs and GPU memory corruption from renderer code.

Implementation:

• Spawn gosub-gpu-daemon (GPU worker) with exclusive GPU device access
• Renderer child process submits GPU commands to GPU daemon
• GPU daemon executes wgpu rendering and returns texture IDs
• Prevents: GPU driver exploits, GPU memory leaks, GPU command injection

---

Out of Scope (Future Work)

• JavaScript Isolation: V8 in separate process per origin (very large change)
• HTML/CSS Parser Isolation: Separate process for parsing (complex; parsing is sequential)
• Storage Process: Separate process for cookies/localStorage (lower priority)

---

Security Model After Implementation

Component	Current	After Phase 1	After Phase 2	After Phase 3
Network can access other zones' data	✅ Yes	❌ No	❌ No	❌ No
Renderer can access other origins' cookies	✅ Yes	✅ Yes	❌ No	❌ No
Renderer can forge requests	✅ Yes	❌ No	❌ No	❌ No
GPU exploit can crash browser	✅ Yes	✅ Yes	✅ Yes	❌ No

---

Testing Strategy

• Add integration tests for IPC message framing (corruption handling)
• Add tests for process crash recovery (orphan process cleanup)
• Benchmark: measure frame time delta before/after Phase 2
• Security test: verify renderer child cannot read parent memory
• Security test: verify network process cannot access tabs' data

---

References

• Chromium Architecture: Process Model
• WebKit: Multi-Process Architecture
• Current code:
  • /crates/gosub_engine/src/engine/engine.rs — Engine entry point
  • /crates/gosub_engine/src/engine/tab/worker.rs — Tab worker (currently runs in Tokio task)
  • /crates/gosub_engine/src/net/io_runtime.rs — Network I/O (currently in Tokio task)

---

Acceptance Criteria

• Phase 1 complete: Network process isolated, SSRF prevented
• Phase 2 complete: Renderer per-origin, origin data isolation enforced
• IPC layer: Robust (handles process crashes, message corruption)
• Performance: <10ms added latency per frame (Phase 2)
• Tests: 90%+ coverage for IPC layer and process lifecycle
• Documentation: Updated with new architecture diagrams

[Sharktheone]

So, I feel like this should all be "optional"

Basically we have a trait for communication (we already had that in the old gosub). The individual modules are then fully unaware if they are communication via IPC or direct channels.

I would really like that we use shared memory rather than (unix) sockets for IPC.

[jaytaph]

Define "optional"? In theory we could run everything within a single process (like we do now), but it has major security drawbacks: a malicious html or image could be able to access other tab data or even the main process data (which may include secret keys or password managers as extension).

I think we could make the system optional in a sense that we can have it feature-gated where we don't spawn new processes.

For IPC, I think we should have a mixture of both: shared memory is perfect for dealing with our large texture data that are generated by separate CPU/GPU renderers. But we need some kind of sync for that (although we have some already in the tiles itself).

For messages like network and engine commands, we should use traditional sockets, as they are much more efficient when we combine it with either bincode or even json (although i don't like the json overhead). These commands are minimal in both quantity and size so the overhead is negligable.

I think we can use the communication trait (i don't know if this is still in the gosub codebase tbh) which allows us to swap in different systems if we want to (chromium uses mojo and idl, but i don't think we need that right now)

[Sharktheone]

The main usage for this feature will be embedded use cases. Like when there is a small gui on some device. Then everything has less overhead on an already restricted system.

This is not for an actual browser, but more a "WebView".

I don't want to make it feature gated. I think it makes the most sense if we already define that in our APIs, basically, something like a RequestServer or GPUProc returns a handle. That handle might be to a different proc or just a different thread or it might do everything inline.

Multiple request servers idea

//This should be seen more like a Handle
trait RequestServer {
    async fn get(&mut self, url: Url, headers: Headers, ...) -> Response
    async fn post(&mut self, url: Url, content: Bytes, headers: Headers, ...) -> Response
}


// Then we might have different RequestServers




enum Req {
    Get(Url, Headers, usize),
    Post(Url, Bytes, Headers, usize),
}


struct ThreadedRequestServer { 
    tx: Channel<Req>,
    rx: Arc<RespStorage>,
}



impl RequestServer for ThreadedRequestServer {
    async fn get(&mut self, url: Url, headers: Headers, ...) -> Response {
        let id = self.next_req_id();
    
        self.tx.send(Req::Get {url, headers, id});
        
        self.rx.wait_for(id).await
    }
    
    ...
}

struct IsolatedRequestServer { 
    tx: IpcChannel<Req>,
    rx: SharedMemory<RespStorage>,
}



impl RequestServer for IsolatedRequestServer {
    async fn get(&mut self, url: Url, headers: Headers, ...) -> Response {
        let id = self.next_req_id();
    
        self.tx.send(Req::Get {url, headers, id});
        
        self.rx.wait_for(id).await
    }
    
    ...
}


struct InlineRequestServer { 
    client: reqwest::Client,
}



impl RequestServer for InlineRequestServer {
    async fn get(&mut self, url: Url, headers: Headers, ...) -> Response {
        self.client.get(url, headers).await
    }
    
    ...
}

[jaytaph]

I've set up a proof-of-concept for this: https://github.com/gosub-io/poc-multi-process

Either the code can be ran multi-process or single-process. It will deal with security boundaries between processes so we don't leave access open to the OS network stack when we don't need it (the tab/render processes for instance)..

The whole setup is based on the global setup from other browsers. IPC is used and only has a minimal and negligable overhead when dealing with events. Large memory blobs like images from the network process can be send over through shared memory.

a single-process does basically the same, but has everything in a threads. It's not 100% foolproof yet, but the basic security measurements are implemented and since the design mimics the gosub engine itself, it would not be very difficult to implement this into the engine itself.