-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable speaker output for domUs by default #2724
Comments
This issue is being closed because:
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: 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): 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 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. |
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
The text was updated successfully, but these errors were encountered: