qubes-issues

qubes-issues copied to clipboard

To prevent them from communicating to other mic-equipped devices and deanonymizing the user. (Note we do not expose mic to any AppVM by default since forever.)

Seems like we can easily do that during installation via Salt config. But maybe consider also some runtime check to ensure this also (in Qubes 4.x)?

/cc @adrelanos

This issue is being closed because:

• This issue has the "Release 3.2 updates" milestone.
• Qubes OS 3.2 recently reached end-of-life (EOL).
• This issue has not been updated in over a year.

If anyone believes that this issue should be reopened, please let us know in a comment here.

Please re-open. Applies to any milestone.

Microphones and speakers are a risk for all VMs, Whonix and non-Whonix, see: https://www.kicksecure.com/wiki/Hardware_Threat_Minimization

Therefore this isn't a Whonix specific task. The sane default would be to attach neither a microphone nor a speaker to any VM. In other words, VMs should be microphone-less and speaker-less by default.

Suggested title (feel free to use a better one): disable speaker output for all VMs by default

Opt-in could be similar to how android asks if a permission should be granted (such as GPS) as soon as the app attempts to use the device.

Therefore also tag C: Whonix is inappropriate.

Instead of disabling audio output altogether, I think a much better approach would be for audio output to be enabled, but muted by default. I suspect this is much less likely to break buggy programs that do not handle audio device hotplug and/or stream corking well, and the attack surface is identical as 0 * x = 0 no matter what X is (no, floating point trickery is not useful here).

I have a little bash menu script I run. Hitting 'm' mutes all VMs and dom0, while 'M' unmutes all.

Configuring anything more fiddly requires going into the PA control panel.

B

I have a little bash menu script I run. Hitting 'm' mutes all VMs and dom0, while 'M' unmutes all.

I just added something like that here.

However the default on VM start should still be "muted" as that approach doesn't help with disposable VMs started later.

Agreed.

Leaning toward auto-muting disposables (or perhaps all VMs?), perhaps controlled by a global setting (or two)?

Default setting might be audio enabled but guide could reference changing the flag (for vulnerable users). Really a development team call.

B

As this issue is 5 years old, I rediceded and added a daemon to execute arbitrary code - incl. VM mutes - on VM starts, stops, ... etc. here.