Mark/devforge

Fork 0

HIGH: USB device passthrough grants all session containers host USB access #24

New issue

Closed

opened 2026-05-08 23:50:08 +00:00 by Mark · 3 comments

Mark commented

2026-05-08 23:50:08 +00:00

Owner

Issue

Every session container is created with full read-write access to all host USB devices. This is a significant container escape vector — if a session container is compromised, the attacker can interact with any USB device on the host.

Location

services/api/app/docker_manager.py:219

Current Implementation

container = client.containers.create(
    ...
    devices=["/dev/bus/usb:/dev/bus/usb:rwm"],
    ...
)

The rwm mode gives read, write, AND mknod (device creation) access to all USB devices.

Risk

Any session container can access ALL USB devices on the host
Malicious code in a session could exfiltrate data from USB security keys, storage devices, etc.
Could be used to install malicious USB device firmware
Provides a mechanism to escape the container via USB device interaction

Proposed Fix

Remove the global USB device mount entirely unless explicitly needed
If USB access is required, make it opt-in per session with user consent
Restrict device access to specific USB devices rather than all of /dev/bus/usb
Use read-only mode (ro) instead of rwm if write access isn't strictly required

Priority: High
Type: Security

## Issue Every session container is created with full read-write access to all host USB devices. This is a significant container escape vector — if a session container is compromised, the attacker can interact with any USB device on the host. ## Location - `services/api/app/docker_manager.py:219` ## Current Implementation ```python container = client.containers.create( ... devices=["/dev/bus/usb:/dev/bus/usb:rwm"], ... ) ``` The `rwm` mode gives read, write, AND mknod (device creation) access to all USB devices. ## Risk - Any session container can access ALL USB devices on the host - Malicious code in a session could exfiltrate data from USB security keys, storage devices, etc. - Could be used to install malicious USB device firmware - Provides a mechanism to escape the container via USB device interaction ## Proposed Fix 1. Remove the global USB device mount entirely unless explicitly needed 2. If USB access is required, make it opt-in per session with user consent 3. Restrict device access to specific USB devices rather than all of /dev/bus/usb 4. Use read-only mode (`ro`) instead of `rwm` if write access isn't strictly required **Priority:** High **Type:** Security

Mark added the

blocked:needs-decision

label

2026-05-11 23:00:06 +00:00

Mark commented

2026-05-11 23:00:06 +00:00

Author

Owner

This is a security/design issue that needs human review before action.

Mark added

blocked:no-procedure

and removed

blocked:needs-decision

labels

2026-05-15 21:00:01 +00:00

Mark commented

2026-05-16 00:34:16 +00:00

Author

Owner

Ops Pipeline — No Executable Procedure

Research did not produce any executable commands.

Now I have the full picture. Let me read the exact context of the change needed.

The code at /home/b/Projects/devforge/services/api/app/docker_manager.py line 222-224 conditionally attaches ALL host USB devices with :rwm (read, write, mknod) for three profiles: oh-my-opencode, oh-my-opencode-lite, and custom. The standard and base-config-editor profiles are already clean.

HOST: localhost
STATUS: EXECUTABLE
EVIDENCE: The USB passthrough is at line 222-224 of docker_manager.py. I

## Ops Pipeline — No Executable Procedure Research did not produce any executable commands. Now I have the full picture. Let me read the exact context of the change needed. The code at `/home/b/Projects/devforge/services/api/app/docker_manager.py` line 222-224 conditionally attaches ALL host USB devices with `:rwm` (read, write, mknod) for three profiles: `oh-my-opencode`, `oh-my-opencode-lite`, and `custom`. The `standard` and `base-config-editor` profiles are already clean. HOST: localhost STATUS: EXECUTABLE EVIDENCE: The USB passthrough is at line 222-224 of `docker_manager.py`. I

Mark added

triage-approved

and removed

blocked:no-procedure

labels

2026-05-28 07:23:04 +00:00

Mark added

blocked:gate-plan

and removed

triage-approved

labels

2026-05-29 16:44:47 +00:00