[GH-ISSUE #4] [FEATURE] Implement --capability-policy for security filtering #5

New issue

Closed

opened 2026-10-30 21:32:21 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-30 21:32:21 +00:00

Owner

Originally created by @joleuger on GitHub (Jan 3, 2026).
Original GitHub issue: https://github.com/joleuger/vuinputd/issues/4

Context

As discussed in ValveSoftware/steam-devices#71, exposing raw access to /dev/uinput inside a container can be a security risk ("BadUSB" attacks, VT switching, etc.).

We need a way to restrict what kind of devices a container is allowed to create.

Proposed Solution

Add a command line argument --capability-policy (or --limit) to vuinputd that enforces specific profiles during the UI_DEV_CREATE and UI_SET_*BIT phases.

Proposed Policies

1. gamepad-only (Strict Mode)

Goal: Prevent creation of generic keyboards or mice. Only allow Gamepads/Joysticks.
Logic:
- Reject UI_SET_EVBIT if it includes EV_KEY ranges outside of standard Gamepad buttons (BTN_SOUTH, BTN_START, etc.).
- Explicitly reject standard alphanumeric keys (KEY_A, KEY_1, etc.).
- Allow EV_ABS (Analog sticks).
- Edge Case: Xbox controllers technically send some keyboard keys (like the Guide button or screenshot). We need a whitelist of allowed "Gamepad-adjacent" keys.

2. sanitized (Safe Desktop Mode)

Goal: Allow Keyboards and Mice for gaming (WASD, chat) but prevent host takeover.
Logic:
- Allow standard EV_KEY ranges.
- Blacklist: KEY_SYSRQ (Magic SysRq), KEY_POWER, KEY_SLEEP.
- Stateful Filtering: In the write() handler, drop dangerous combinations like:
  - Alt + F1-F12 (VT Switching)
  - Ctrl + Alt + Del

3. unrestricted (Default)

Legacy behavior. Allow everything.

Implementation Details

This should likely be checked in the ioctl handler for UI_SET_KEYBIT. If a client tries to enable a forbidden bit for the active policy, we should either return -EPERM or silently ignore the bit setting.

Originally created by @joleuger on GitHub (Jan 3, 2026). Original GitHub issue: https://github.com/joleuger/vuinputd/issues/4 ## Context As discussed in [ValveSoftware/steam-devices#71](https://github.com/ValveSoftware/steam-devices/issues/71), exposing raw access to `/dev/uinput` inside a container can be a security risk ("BadUSB" attacks, VT switching, etc.). We need a way to restrict what kind of devices a container is allowed to create. ## Proposed Solution Add a command line argument `--capability-policy` (or `--limit`) to `vuinputd` that enforces specific profiles during the `UI_DEV_CREATE` and `UI_SET_*BIT` phases. ### Proposed Policies **1. `gamepad-only` (Strict Mode)** * **Goal:** Prevent creation of generic keyboards or mice. Only allow Gamepads/Joysticks. * **Logic:** * Reject `UI_SET_EVBIT` if it includes `EV_KEY` ranges outside of standard Gamepad buttons (`BTN_SOUTH`, `BTN_START`, etc.). * Explicitly reject standard alphanumeric keys (`KEY_A`, `KEY_1`, etc.). * Allow `EV_ABS` (Analog sticks). * *Edge Case:* Xbox controllers technically send some keyboard keys (like the Guide button or screenshot). We need a whitelist of allowed "Gamepad-adjacent" keys. **2. `sanitized` (Safe Desktop Mode)** * **Goal:** Allow Keyboards and Mice for gaming (WASD, chat) but prevent host takeover. * **Logic:** * Allow standard `EV_KEY` ranges. * **Blacklist:** `KEY_SYSRQ` (Magic SysRq), `KEY_POWER`, `KEY_SLEEP`. * **Stateful Filtering:** In the `write()` handler, drop dangerous combinations like: * `Alt` + `F1-F12` (VT Switching) * `Ctrl` + `Alt` + `Del` **3. `unrestricted` (Default)** * Legacy behavior. Allow everything. ## Implementation Details This should likely be checked in the `ioctl` handler for `UI_SET_KEYBIT`. If a client tries to enable a forbidden bit for the active policy, we should either return `-EPERM` or silently ignore the bit setting.

bsakaguchi referenced this issue

2026-10-30 21:32:21 +00:00

[GH-ISSUE #5] Isolation from host #6

bsakaguchi closed this issue

2026-10-30 21:32:21 +00:00