Option to hide source qube name from destination qube when copying files between qubes

[jamke]

The problem you're addressing (if any)

Currently if user copies files from some private qube to some less secure, online or even malicious qube, it gets the name of the source qube for no particular reason. It happens due to the naming of directories after qubes inside QubesIncoming.

The solution you'd like

The GUI dialog with target qube selection should have a checkbox Put in common subdirectory. In this case the copied files should be put in place like QubesIncoming/common.

In case it is desired to avoid conflicts with existing qube named common, it can be QubesIncoming/_common_ or some name that as chars not allowed in qubes' names. But I think even common is fine.

The value to a user, and who that user might be

The target qube, quite often much less secure, sometimes malicious, will not get information about users internal qubes structure. Especially considering it is completely not necessary in the first place to share source qube name with the target qube.

[xaki23]

i mostly disagree with this one. as long as it is optional and not checked by default, okay, but meh, i dont see any benefit. if the names of your qubes are sensitive, wth is going on?

[jamke]

if the names of your qubes are sensitive, wth is going on?

Maybe, I did not get your question.

Nonetheless, I will try to answer: it does not have to be sensitive, it can be kind of unique. This way any software that runs in target qubes can make logical connection for 2 separated source qubes, even offline ones even, when they use TOR, VPN, harden Firefox or anything else. To say with high probability those qubes run on the same PC. And this information can help with a targeted attack.

And there is ZERO reason to have this situation unavoidable, at least there is no technical problem to make it optional in the way I proposed. It will not negatively affect security, but improve both privacy and security.

i mostly disagree with this one.

It is an enhancement ticket. If somebody has 5-20 qubes with default names and do not need this feature, it does not mean that everybody does not need it, too, right?

Also, it explicitly says that the change of target directory is optional controlled by checkbox, because otherwise there can be a clutter in the target directory made by different qubes.

[ben-grande]

And there is ZERO reason to have this situation unavoidable, at least there is no technical problem to make it optional in the way I proposed. It will not negatively affect security, but improve both privacy and security.

There is a lot of reasons, split-gpg2 uses the client domain to acquire the correct keyring, split-gpg uses to show the notification. I use it on Qrexec services to do different things. It does not improve security, in decreases it, it is easy to mess up when you don't know from which client qube the file came from, as multiple could upload to common directory. You might remember on the same hour which qube uploaded what, but then time passes and humans do not have a perfect memory.

Adding popups would not fix the problem. This creates friction with Qrexec calls that should be allowed but now have to be answered to a popup that was not expected to have user interaction.

All Qrexec services have the client qube name acquired via $QREXEC_REMOTE_DOMAIN, changing solely qubes.Filecopy would not fix the issue you intend too.

Try this in dom0 to see how many servers can have you client qube name (not that you are actively calling all of them):

qrexec-policy-graph --include-ask --source CLIENT_QUBE

Also note that on R4.2, the graph is correct where on R4.1 is lacks some information.

For example, templates uses the qubes.UpdatesProxy service, the server qube has access to their names, it could try to do different things per name, this would be useful to set different routes etc. When using qubes.OpenInVM or qubes.OpenURL via qvm-open-in-vm, qvm-open-in-dvm, they also have the client qube name. A popup for these services means too popups, as they are set to ask policy resolution by default, adding friction.

I agree that I do not want the target qube to always know the client qube name, but an extra popup is not the solution as explained above. If you want this done, it would need to be on the Qrexec level, that I think would be possible to do, does not require an extra popup, but then packagers would need to be informed that QREXEC_REMOTE_DOMAIN might be unset or set a specific @common string.

[jamke]

@ben-grande

There is a lot of reasons, split-gpg2 uses the client domain to acquire the correct keyring, split-gpg uses to show the notification. I use it on Qrexec services to do different things.

Sorry, I did not get it. In the enhancement ticket it is explicitly said, that the location (with qube name or without) will be made by user with CHECKBOX and in the EXISTING popup. So:

• no additional popup is required (you meant this, or I did not understand you right?),
• if you do not ever click this checkbox and do not use the requested feature - EVERYTHING will work for you the same way as it works now, you understand it, right?
• all existing ways of using split-gpg2 or anything will still work as expected both out of box and by default.

This change offers additional optional feature. Please re-read the provided proposal, maybe you misunderstood me. Or I did not understand you.

[marmarek]

Source qube name is quite important for the destination, as explained by @ben-grande . But I can see there might be some rare cases where it would be useful to hide it, for example when opening a file from offline qube in a disposable qube. But note, if you want to hide file origin, for more complex file formats you'll likely need some extra work, for example PDF, DOCX, ODT etc include metadata about where they were created/modified (usually user name, computer name etc).

And let me repeat what was said earlier already: such feature is a massive foot-gun. Imagine sending image.jpg to some qube from a trusted qube. But you forgot you copied image.png to that qube earlier from a totally different place. Without clear separation by the source, it's very easy to make mistake and use the wrong file.

If adding such a feature (which I'm still not sure if it's a good idea at all), it would need to be done at qrexec level, not just individual service level. This will probably require additional policy setting, for example:

# hide-source=yes always hides the source name - with "allow" action there is no confirmation dialog
qubes.Filecopy * some-vm another-vm allow hide-source=yes
# with "ask" action, the confirmation dialog will not have the option, hide-source=yes always hides the source name
qubes.Filecopy * @anyvm another-vm ask hide-source=yes
# with "ask" action, allow-hide-source=yes will let the user decide (by default to not hide)
qubes.Filecopy * @anyvm @anyvm ask allow-hide-source=yes

And then appropriate change to the prompt dialog and its API.

At the qrexec protocol level, the source name is a mandatory field. It would need to be filled with some dummy value that do not collide with any qube name. We have few names as reserved values, like none, but maybe it should be some keyword like @unknown? The directory name used by qubes.Filecopy service is secondary, the service can translate it into some human friendly name.

[ben-grande]

@jamke

• no additional popup is required (you meant this, or I did not understand you right?),

You understood me right but I understood you wrong, a checkbox in the same dialog is better than two popups. I misinterpreted this part.

• if you do not ever click this checkbox and do not use the requested feature - EVERYTHING will work for you the same way as it works now, you understand it, right?

For some services it will have unintended results.

• all existing ways of using split-gpg2 or anything will still work as expected both out of box and by default.

Won't, for split-gpg2, common name should never be set unless you want shared keys queried, signed, decrypted by all the common clients.

https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/95fb34da0ccc0102d53dabd6399f93cb9e757454/splitgpg2/__init__.py#L1428

---

@marmarek does propose the solution on the Qrexec level protocol, which involves a lot of files, not only adding a checkbox for one service, but the correct way is:

• change Qubes RPC services to handle a hidden remote
• change Qrexec policy handler to handle this parameter hide_source=(yes|no), default to no
• change Qrexec dialog box
• documenting this new feature on the Qrexec internals and Qrexec policy page
• warn users that services needs to support the remote name to be hidden
• to be added to all dialogs, which means a unified dialog (already the case)

[jamke]

Won't, for split-gpg2, common name should never be set unless you want shared keys queried, signed, decrypted by all the common clients.

Why? Just do not click this checkbox for copying to that particular custom qube (than most of the users don't even have) and everything will work as you expect. It is your decision to hide the source qube or not hide [default],

---

But I can see there might be some rare cases where it would be useful to hide it, for example when opening a file from offline qube in a disposable qube. But note, if you want to hide file origin, for more complex file formats you'll likely need some extra work, for example PDF, DOCX, ODT etc include metadata about where they were created/modified (usually user name, computer name etc).

That I agree and understand. It's always a case. But I am not afraid of copying jpeg, txt files from more private (e.g. offline) qubes to more public ones, because I can strip metadata from them. But it currently provides target qube information about my internal qubes structure (qubes names) and I see no reason why it should be always the case.

it would need to be done at qrexec level, not just individual service level. This will probably require additional policy setting, for example

Looks interesting, I mean it is more complicated that I expected, and I personally wouldn't probably use at full such flexible limitations, but looks correct and logical.

What I would use is setting this checkbox default on for some (unsafe) qubes. It would be great to have it implemented as checkbox with a button to remember this choice that will manage policies if it is not against Qubes OS workflow. From the UI perspective it can be implemented as in qbittorrent for the dialog of removing the torrent. It has a button on the left of checkbox that saves the default checkbox state for the next calls, the button has tooltip, so it is clear what it does, and if user does not want to use this feature they can ignore the line with checkbox completely.

---

It would need to be filled with some dummy value that do not collide with any qube name. We have few names as reserved values, like none, but maybe it should be some keyword like @unknown?

As I said, it seems to be a good idea to use some char that is not allowed in qube's name, so making it @unknown or @hidden looks as a good idea. Even the target directory inside QubesIncoming can be named the same.

Thanks everybody for discussion anyway, it is not a so important feature but clear how to implement and clear how to use one.

P.S. To upload this screenshot here I had to show this online qube the name of the qube I made modifications in. And it was inevitable, because:

• I was not able to crop it in dom0 as it has no editor,
• I was not able to crop it in target qube (copy screenshot directly from dom0), because it will get the whole screenshot data with other qubes open,
• I was not able to hide the source offline qube with editor installed, because the discussed feature is not implemented.

And this information can be stored in target unsafe qube in many places: in logs, recent files, some last directory/file entry in pieces of software, even after I remove the directory in the target qube.

[ben-grande]

What I would use is setting this checkbox default on for some (unsafe) qubes. It would be great to have it implemented as checkbox with a button to remember this choice that will manage policies if it is not against Qubes OS workflow. From the UI perspective it can be implemented as in qbittorrent for the dialog of removing the torrent.

Seeing the example and thinking again, it can not be a checkbox and not even remeber this option for later. This would complicate things. Qrexec policy has the directories /etc/qubes/policy.d and /etc/qubes/rpc-config and none support the dialog writing the configuration.

Please bear in mind that you are only considering the frontend, not the backend.

If you want this done, focus on Marek's points:

And let me repeat what was said earlier already: such feature is a massive foot-gun. Imagine sending image.jpg to some qube from a trusted qube. But you forgot you copied image.png to that qube earlier from a totally different place. Without clear separation by the source, it's very easy to make mistake and use the wrong file.

If adding such a feature (which I'm still not sure if it's a good idea at all), it would need to be done at qrexec level, not just individual service level. This will probably require additional policy setting, for example:

And debate that,the disadvantages of hiding the source, not the the frontend.

[jamke]

And debate that,the disadvantages of hiding the source, not the the frontend.

To get such rare situation, user deliberately have to decide to send several files that are not allowed to be swapped to common directory. The answer to avoid such situation is simple: it you are afraid to take wrong file, or file is so special that the origin qube should be preserved, just do not use this feature for copying this file or even never use. I see no problem what so ever from this point of view. We are not removing delete file feature just because user can easily (way more easy and with many times higher probability) remove the wrong file.

About backend. I am not sure that all these complications are necessary. Is it required to involve policy files in the first place? Only dom0 user makes decision use it or not each time and explicitly. The setting (checkbox) can be clear out each time. At least it will allow to set it each time, still better that how it works now, when there is no ability to prevent leak of unrelated offline qube names to software in the unsafe qube.