Use default allow for qubes.FileCopy service

[rootkovska]

We want to minimize the amount of prompts which only train the user to hit yes to get work done. qubes.FileCopy has been designed to be safe even if the srcvm is malicious, so it's rational to use default allow here IMHO.

[andrewdavidwong]

This seems dangerous, since it makes it easy for a novice user to unwittingly transfer a file from a less secure domain to a more secure domain, then (wondering what this curious new file is that mysteriously appeared in the more secure domain) open it. Prompt fatigue is already handled by providing the option to choose "always allow." This keeps the user in control of deciding whether she considers prompt fatigue a bigger risk than accidentally moving files to the wrong domains.

[marmarek]

Additionally, and more importantly, having "allow" by default here may compromise user privacy - for example if compromised VM (DispVM / Whonix VM / ...) can trivially leak traces to other, persistent VMs, which later could be correlated with the user. The same applies in opposite direction - compromised sys-net could place some indicator in almost every VM, to correlate user actions.

So, I agree that we shouldn't enable this by default unconditionally. Maybe create "allow" rules for default VMs (using mgmt stack)? Or somehow encourage users for using "always allow" for "safe" transfer directions (and make accidental confirmation harder, #1166 (comment))?

[tasket]

Although prompt fatigue is a valid security concern, I think we should respectfully pass on this idea. Marek's initial point is valid, and its worse to create an atmosphere where users fear correlation attacks and feel they need to be adjusting and re-adjusting this setting when they manage their VMs.

The current default best balances usability and security because fundamentally there is no way for Qubes to guarantee that even the most trusted domUs are not compromised (whether or not the malware is disk-based or RAM-only).

OTOH, having a dom0 qvm-copy that can copy between 2 domUs without prompts could be nice (even though qvm-run/cat works).

IMHO -- I think ITL needs to be very careful about UX enhancements for two reasons: 1) FOSS does poorly here in the first place and the offerings are chaotic, and 2) this is unfortunately not your specialty and its easy to underestimate the difficulty of envisioning and implementing operating system UIs. Even so, Qubes concept did hit on something rather unique: GUI that is essentially vertically integrated with the deep security contexts in the system. As an avid watcher of MS and Apple designs since the 80s, and the fumblings of FOSS UIs, I see the current situation as fairly decent in addition to offering some exciting visualization/monitoring possibilities for the future.

[WhiteWinterWolf]

Hello,

Let's say I download a file from the web (let's say in an AppVM called web-untrusted) and archive it in a network-less AppVM (let's say it is called archive) with other files I want to store out of reach of browser and other network-enabled software.

Let's say this file happens to bring a malicious payload. My expectation is that, while the file may potentially corrupt, infect or delete other files in the archive AppVM (thus forcing me to restore a sane backup of this AppVM), this AppVM being network-less the malicious payload will have no easy way to exfiltrate the content of this AppVM.

If I understand correctly this suggestion, such malicious payload would now be able to dump the whole content of the archive AppVM inside web-untrusted AppVM (maybe dozen of GB, hundreds of files) without the user noticing, making them reachable from a networked and potentially exploited browsers or email software (the interest of exploiting browsers and email software is that it allows in turn to infect legitimate files downloaded by the user, making the second stage of this attack easier).

Would such threat make sense, or would it fall outside of Qubes scope? I'm asking this because of this post:

I would like to make it clear that we are not interested in eliminating cooperative covert channels between domains in Qubes any time in the near future, and perhaps in the long term as well. I just don't believe into such approach, and I also don't like that this approach does nothing to preserve the integrity of the more-trusted domain it only focuses on the isolation aspect.

From this point of view I understand the logic behind eliminating the prompt, however personally I would not feel safe knowing that large amount of data may be transferred from one AppVM to another without me knowing it, nor would I feel safe in using an OS with what I perceive to be insecure defaults for the sake of "usability".

Speaking of usability, I think the prompt should not be deleted but instead be improved to better highlight the source and destination AppVM. I agree with Andrew about the "Always allow" button.

Regards,

[marmarek]

Ok, I think we all agree it isn't the best idea to implement this change.