Skip to content

Conversation

@deeplow
Copy link
Contributor

@deeplow deeplow commented Jan 30, 2026

Deny attachment of devices except to sd-devices. This is a temporary workaround while there is no salt support for QubesOS/qubes-mgmt-salt-dom0-qvm#36. Once we have that we can add it under qvm.prefs.

This also adds a test where it creates a block device exposed in sys-usb and then attempts to attach it the expected qube. Unfortunately there was not enough information in the qvm-block attach command and systemd journal logs were necessary to confirm the attach denial.

Fixes #1428. Depends on #1373 (change base to main once that's merged)

Test plan

  • (Qubes 4.2) Passing on OpenQA should be sufficient, since it shows that devices_denied is not being applied (otherwise it would fail)
    Qubes 4.3:
  • Insert USB drive and attempt to attach to sd-app
  • The devices widget should prevent it (blocked by policy)
    policy

Checklist

This change accounts for:

  • any necessary RPM packaging updates (e.g., added/removed files, see MANIFEST.in and rpm-build/SPECS/securedrop-workstation-dom0-config.spec)
  • any required documentation

This prevents the accidental attachment of a would-be malicious device
to highly sensitive qubes. It takes advantage of Qubes' 4.3 features.

Fixes #1428
Prevent the device attachment denial, since this is a feature only
available since Qubes 4.3.
The fixture 'mock_block_device' was unable to run in parallel tests. The
issue is related to the paralellization introduced in [1].

[1]: #1512
Necessary to inpect systemd journals
The device denial message is too generic to know that it was in fact the
problem ("Error: Got empty response from qubesd"). This could occlude
other problems with qubesd.

This adds a 'qubesd_log' fixture and uses it to search for the exact device
attachment message.

An alternative approach of mocking qubesd was considered but that would
be a more complex solution and the fact that qvm-block was called
through a subprocess would have made that mocking more complex.
@deeplow deeplow requested a review from a team as a code owner January 30, 2026 16:28
@deeplow deeplow moved this to Blocked or Waiting in SecureDrop Jan 30, 2026
@deeplow deeplow added 4.2-openqa-pending Run on OpenQA (Qubes 4.2) and removed 4.2-openqa-pending Run on OpenQA (Qubes 4.2) labels Jan 30, 2026
@deeplow
Copy link
Contributor Author

deeplow commented Jan 30, 2026

In order for OpenQA to run we need to either wait for #1373 to be merged and then rebase this on main to pick up the OpenQA label changes in #1548

@deeplow deeplow self-assigned this Jan 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

4.2-openqa-pending Run on OpenQA (Qubes 4.2) Qubes 4.3

Projects

Status: Blocked or Waiting

Development

Successfully merging this pull request may close these issues.

1 participant