Let user specify other destination folders for file copying

[tasket]

There are many times when a user may want to copy very large files to volumes other than /rw/home, ie on an external HD or even from one external HD to another. Since the 'mount --bind' trick no longer works, that leaves the user writing piped qvm-run commands in dom0 CLI to avoid the waste of copying the data into /rw/home internal volume in an additional step (plus wear and tear).

I suggest adding a single context menu item to nautilus that allows a user to specify in a destination VM where the next file copy will go. It could remain in effect only once for each time the user selects that menu function, or maybe remain in effect for an entire session (until the dest VM is restarted).

[rustybird]

Since the 'mount --bind' trick no longer works

What do you mean? Bind mounting something to ~/QubesIncoming/ or ~/QubesIncoming/srcvm/ works for me, as does symlinking. Maybe your target filesystem does not support the required operations? (For example, sshfs is problematic.)

[rustybird]

Since the 'mount --bind' trick no longer works

What do you mean? Bind mounting something to ~/QubesIncoming/ or ~/QubesIncoming/srcvm/ works for me, as does symlinking. Maybe your target filesystem does not support the required operations? (For example, sshfs is problematic.)

[tasket]

Hmmm... bind is working with QubesIncoming again. I stopped using HFS+ as an offline filesystem so that may have been a factor.

I still think letting the user select alt. destination from the GUI is good for UX.

[tasket]

Hmmm... bind is working with QubesIncoming again. I stopped using HFS+ as an offline filesystem so that may have been a factor.

I still think letting the user select alt. destination from the GUI is good for UX.

[bnvk]

@ttasket just to confirm, are you meaning something like in a file Copy / Move dialogue, the user gets presented with a menu like

Copy to

• QubesIncoming
• Specify Other Folder

Whereby selecting Specify Other Folder gives user a dialogue prompt to input a custom path or select from a GUI file browser?

@marmarek is this sort of thing possible given the security model?

[bnvk]

@ttasket just to confirm, are you meaning something like in a file Copy / Move dialogue, the user gets presented with a menu like

Copy to

• QubesIncoming
• Specify Other Folder

Whereby selecting Specify Other Folder gives user a dialogue prompt to input a custom path or select from a GUI file browser?

@marmarek is this sort of thing possible given the security model?

[marmarek]

@marmarek is this sort of thing possible given the security model?

Source VM can't control target directory, otherwise it would be able put file in some place expected to be trusted by the user.
This may be some additional setting/dialog in target VM. As noted somewhere before, it should still force source VM named subdirectory there.
This may be also integrated into new confirmation dialog (#910), but not sure it would be the best idea, because generally we want to get rid of as much confirmations as possible to improve UX (and also confirmations are generally not really secure, because #1166 and additionally many users don't read them at all...).
As for file copy - if target directory is forced to be something clearly coming from different VMs (as it is now), there may be no confirmation at all.

[marmarek]

@marmarek is this sort of thing possible given the security model?

Source VM can't control target directory, otherwise it would be able put file in some place expected to be trusted by the user.
This may be some additional setting/dialog in target VM. As noted somewhere before, it should still force source VM named subdirectory there.
This may be also integrated into new confirmation dialog (#910), but not sure it would be the best idea, because generally we want to get rid of as much confirmations as possible to improve UX (and also confirmations are generally not really secure, because #1166 and additionally many users don't read them at all...).
As for file copy - if target directory is forced to be something clearly coming from different VMs (as it is now), there may be no confirmation at all.

[andrewdavidwong]

Source VM can't control target directory, otherwise it would be able put file in some place expected to be trusted by the user.

But we're not supposed to be copying from less trusted -> more trusted domains in the first place, right?

[andrewdavidwong]

Source VM can't control target directory, otherwise it would be able put file in some place expected to be trusted by the user.

But we're not supposed to be copying from less trusted -> more trusted domains in the first place, right?

[andrewdavidwong]

As for file copy - if target directory is forced to be something clearly coming from different VMs (as it is now), there may be no confirmation at all.

No confirmation by default (default RPC "allow"), or simply no option to have a confirmation at all (no RPC policy)? If it's the latter, I would worry about no longer protecting against accidental leaks from confidential source VMs.

[andrewdavidwong]

As for file copy - if target directory is forced to be something clearly coming from different VMs (as it is now), there may be no confirmation at all.

No confirmation by default (default RPC "allow"), or simply no option to have a confirmation at all (no RPC policy)? If it's the latter, I would worry about no longer protecting against accidental leaks from confidential source VMs.

[marmarek]

But we're not supposed to be copying from less trusted -> more trusted domains in the first place, right?

Sometimes it isn't that simple. For example what about documents coming via email? Sometimes you want to store them somewhere (outside of email VM), not only open in DispVM directly from email VM.

No confirmation by default (default RPC "allow")

This one. Maybe even not for all the VM (for example transfers out of default "untrusted" VM would still require confirmation, or even be denied by default). This require some more thinking (this is we haven't done that before, even though all the technical infrastructure for it is ready for a long time). Having management stack allows us to setup more advanced defaults (like the one with "untrusted" VM mentioned above).

[marmarek]

But we're not supposed to be copying from less trusted -> more trusted domains in the first place, right?

Sometimes it isn't that simple. For example what about documents coming via email? Sometimes you want to store them somewhere (outside of email VM), not only open in DispVM directly from email VM.

No confirmation by default (default RPC "allow")

This one. Maybe even not for all the VM (for example transfers out of default "untrusted" VM would still require confirmation, or even be denied by default). This require some more thinking (this is we haven't done that before, even though all the technical infrastructure for it is ready for a long time). Having management stack allows us to setup more advanced defaults (like the one with "untrusted" VM mentioned above).

[andrewdavidwong]

Sometimes it isn't that simple. For example what about documents coming via email? Sometimes you want to store them somewhere (outside of email VM), not only open in DispVM directly from email VM.

True. So the question is whether it's worthwhile to deny some control to SourceVMs for the sake of protecting "wrong way" transfers. Since many users rely on "wrong way" transfers in practice and often don't have much of a choice, I agree it's a worthwhile tradeoff.

[andrewdavidwong]

Sometimes it isn't that simple. For example what about documents coming via email? Sometimes you want to store them somewhere (outside of email VM), not only open in DispVM directly from email VM.

True. So the question is whether it's worthwhile to deny some control to SourceVMs for the sake of protecting "wrong way" transfers. Since many users rely on "wrong way" transfers in practice and often don't have much of a choice, I agree it's a worthwhile tradeoff.

[tasket]

My thinking is to have a separate menu item in nautilus that can be selected in the destination VM. It could require that the user already has a folder selected, and would probably put up a notification that the destination for Qubes copy has changed.

[tasket]

My thinking is to have a separate menu item in nautilus that can be selected in the destination VM. It could require that the user already has a folder selected, and would probably put up a notification that the destination for Qubes copy has changed.

[marmarek]

Closing, as this makes it easier for compromised VM to fool the user to compromise some other VM as described in #1793 (comment)

[marmarek]

Closing, as this makes it easier for compromised VM to fool the user to compromise some other VM as described in #1793 (comment)

[boring-stuff]

Yes @marmarek the last comments were OT in #910, but I still don't see your critique to this issue to apply for the reasons specified in this #910 comment.
The point I want to make is: if (as I assume) the security impact is minimal to nonexistent and yet the usability is greatly improved, is it worth it to extend the file transfer agent with this feature?

I am aware that binding works, but I don't think we should default to asking users to do that, especially if they don't master the command line.

[boring-stuff]

Yes @marmarek the last comments were OT in #910, but I still don't see your critique to this issue to apply for the reasons specified in this #910 comment.
The point I want to make is: if (as I assume) the security impact is minimal to nonexistent and yet the usability is greatly improved, is it worth it to extend the file transfer agent with this feature?

I am aware that binding works, but I don't think we should default to asking users to do that, especially if they don't master the command line.