hi dear qubes community, today I am having a general question about saving files in qubes.
an attractive option to do so is the vault as it is (afaik) always disconnected from the internet. surely that mitigates some risks.
nevertheless, the disadvantage of doing so is that i need to copy those files from one VM to another. as the Whonix documentation says, it is risky to copy and paste files from a less trusted VM to a more trusted VM. obviously, the Vault should be more trusted.
I do want to prevent creating any links between my VMs. it is important for me to have them separated. not only from a security point of view, but also in terms of privacy.
the alternative would be to just save the files in the VM’s Thunar File Manager. well, to me it seems like both options have their pros and cons, because the VMs are constantly endangered by potential threats. I wouldn’t feel safe to have important data on VMs that I frequently use, although I’m never downloading anything in those qubes.
If you never open your files inside Vault, then malicious files should not have a chance to attack you. If you want to be even more secure, also never look at the files in a file manager. You can open them in a disposableVM instead.
But this problem – how to handle data flows from less trusted systems to more trusted ones – is not easily solvable in practice, unfortunately…
^ that stood out to me.
I think it becomes more challenging when considering privacy. Perhaps designing a workflow that uses disposables as the source of your files, where possible, would help. Just my thoughts…
In addition to @fsflover’s suggestion not to open files in vault, also consider converting image files and documents to “trusted” files before storing them. Use “convert to trusted PDF” and “convert to trusted IMG” from within the untrusted VM file manager menu prior to copying to your Vault VM. Also note that ghostscript is already installed in your Debian templates (not sure about Fedora), so you can use ps2pdf to convert .ps files to .pdf and convert those as well. Just run ps2pdf <file.ps> in the untrusted VM terminal.
If the untrusted VM is compromised, it can also compromise the “trusted” PDF/IMG file. It’s better to convert it in the trusted environment, or in a dedicated disposable VM.
It does, but it doesn’t eliminate side-channel attacks.
It can still make sense to store certain types of files in offline qubes.
Yes, the Qubes documentation says that too. It’s one of the basic security principles of Qubes (and more generally of handling security domains of different trust levels under certain types of security models).
The phrase “the Vault” suggests that there is (or can be) only one, but that’s not true. There’s no reason you can’t make a separate offline qube (or several) for the express purpose of storing different types of files at different security levels. There is no reason to put your passphrase manager at risk just to have a place to store files offline. The whole point of Qubes is that you can compartmentalize more granularly than that at minimal marginal cost.
With respect to privacy, keep in mind that even offline qubes aren’t leak-proof (due to the aforementioned side-channel risks).
Thunar and other file managers are simply programs that provide a GUI for navigating the filesystem. You don’t store files “in” Thunar any more than the objects you see on the other side of a glass window are “in” that window.
Also, when you say “the VM’s Thunar File Manager,” it’s unclear what “the VM” is referring to. You might mean the originating (presumably online) qube rather than an offline (vault-like) qube. In that case, sure, you can always keep files in the online qube in which they were originally created (e.g., downloaded). That makes sense for certain types of files, but it’s also riskier in certain ways than storing them in a separate, offline qube.
It really depends on your use case and threat model. For example, does it make sense to store your bank statements in the same qube where you do your online banking (and hence where you download those bank statements)? I’d argue that it does, because an adversary who compromises that qube can directly perform bank transactions as if he were you (barring multi-factor authentication outside of that qube), in which case also having access to old bank statements hardly matters. You could still separate them if you wanted to, but it doesn’t seem like you’d be gaining much.
It depends on what exactly you mean.
You have untrusted online qube A.
You have trusted offline qube B.
You wish to securely transfer a file from A to B.
You clone B, creating B’, then copy the file from A to B’.
Now what? All you’ve accomplished is an insecure transfer from A to B’. Sure, B is still safe, but all the contents of B were effectively copied to B’ to when the latter was created, so the contents are now all at risk from side-channel attacks.
And how do you securely re-integrate B and B’? Any transfer from B’ to B would now be an insecure transfer, and deleting B in order to keep B’ would effectively result in the original insecure transfer you sought to avoid but with superfluous steps.
The problem is that disposables are just as susceptible to initial compromise as non-disposable qubes. Being disposable just means the compromise doesn’t have a chance to persist across qube reboots, not that it doesn’t happen in the first place. If the originating disposable becomes compromised, then any transfer from it risks compromising the destination qube.
You’re right. My language was unclear. I meant “less-trusted”, relative to Vault. I personally use a named disposable to process downloaded and USB-transferred files prior to storing them long term in Vault.
@Melly21, I’ve tried to make the title a bit more descriptive than “The vault”. In case you feel my replacement is not a better fit, do feel free to change it.
What we all know is that, for example, all big(ger) companies have numerous bank accounts in numerous banks in numerous countries, as well as probably the vaults, many of them hidden. Most likely for situations when one, or more of them are ripped off, illegally or not…
There’s no reason you can’t make a separate offline qube (or several) for the express purpose of storing different types of files at different security levels.
I actually haven’t thought about that. it’s absolutely right and probably the best way to go. the thing that seems logical to me is to create a Vault for every VM that I use. that way I have them fully separated from each other and each one has their own security level. sounds good?
With respect to privacy, keep in mind that even offline qubes aren’t leak-proof (due to the aforementioned side-channel risks).
so for files which are super super sensitive, I’d have to go with LUKS or VeraCrypt encryption?
regrading side channel attacks: it is malware, right? how big is the risk if I never download anything?
Apologies for my confusing use of scare quotes. I merely meant to imply my doubt in the practicality of always copying data only from more trusted to less trusted qubes.
“B is still safe” is significant since B=vault in this example and the thread was originally titled The Vault. I believe your choice of labeling the clone B’ as opposed to -for example- C, where C’s trust would be evaluated independently of B, indicates where our presumptions diverge. I was also thinking of a fresh install where content should be less of a concern (I think? please correct me if that’s a bad assumption). I guess my preoccupation with my upcoming 4.1 installs led to a poor generalization in my thinking. Appreciate being made aware, though
“Now what?” Since you mentioned separate offline qubes already, I’ll just thank you for your clarity (and use this opportunity to thank you for all your contributions to the Qubes project as well).
Is there any trustworthy method to securely integrate less trusted qubes with more trusted qubes? @adw why did you suggest re-integration? Integrating less trusted qubes with more trusted qubes seems inherently risky to me, especially after spending an inordinate amount of time manually entering data and avoiding up transfers in my vaults.
I did not mean to suggest any sort of re-integration, nor did I intend to imply recommending it. Because I’m skeptical of my ability to thoroughly sanitize qube contents, I suffer with convoluted and inefficient processes to deal with multiple vaults on a few different Qubes machines.
Using Qubes’ backup and restore seems fairly safe for transferring vaults between machines (though I’d appreciate input if anyone disagrees), assuming use of "trusted " hardware (i.e. trusted in the “I have to trust it” sense rather than “it’s deserving of trust”).
Agree on all points; except the lack of persistence across reboots could limit some threat’s window of opportunity, couldn’t it? And wouldn’t the fact that you can restart disposables easily and frequently facilitate shaking off some threat vectors?
Trying to clarify: I find it easier to attempt to limit the exposure of less trusted qubes to my offline qubes by using Qubes’ disposable capabilities. I also thought we might marginally reduce overall risk by using disposable qubes to acquire untrusted files. Is that foolhardy?
For example, we use Tor Browser launched in a dispXXXX (based on whonix-ws-16-dvm) to download an untrusted file. We then copy that file to offline-slight-trust (e.g. a clone of the vault made right after install) and immediately close TB and thus dispXXXX. Since dispXXXX was exposed to Internet threats I would trust it less than offline-slight-trust. Is that reasonable?
Let’s take this example further. Next we open Chrome in dispYYYY which is based on chrome-dvm that connects over clearnet and download the same untrusted file. We rename it file1, copy it to offline-slight-trust, and close Chrome which also shuts down dispYYYY.
I wouldn’t trust either file or file1 in offline-slight-trust. Should we also reduce our trust in the whole offline-slight-trust qube since we copied untrusted files to it from less trusted disposables? Does it make any difference how we copied file and file1 to offline-slight-trust?
Now if we need to compare the checksums of file and file1 and open terminal in offline-slight-trust to run sha512sum are we increasing risk? Would there be any security benefit to using a non-networked disposable for the checksum comparison (i.e. copy both files to an offline disposable and run sha512sum from there)?
I’m under no illusions that disposables are intrinsically less susceptible to compromise because they are disposable. I’m also far from certain limiting exposure in the way I suggested has any appreciable security benefit (that’s why I wrote “Perhaps…”). However I’d like to trust some offline qubes slightly more than disposable qubes which permit untrusted input, if that’s not ill-conceived or ill-advised. Is it?
I sense I’m missing something here. How is my thinking muddled?
Very interested if anyone is willing to share their thoughts. Thanks again
References
How to copy and move files | Qubes OS
“However, one should keep in mind that performing a data transfer from less trusted to more trusted qubes is always potentially insecure if the data will be parsed in the target qube.”
“Therefore, you should always copy data only from more trusted to less trusted qubes.”
Qubes Disposables
“In Qubes, it is unrecommended to store any valuable data in an untrusted VM.”
Multiple Whonix-Workstation
“For instance, if a single Whonix-Workstation ™ was compromised, it could potentially perform various side channel attacks to learn about running processes in other VMs, and not all of these can be defeated.”
How would they be endangered?
If the file could utilise some flaw in the qvm-copy code, then there is
some potential.
If the malware could be triggered by the act of writing to disk.
Otherwise, you can store files without worry.
Of course, it could be that the file contains malware which will be
triggered when the file is opened or run. Make sure that you do
not do this in your vault.
You can help by using a minimal template, and opening files in
disposables. Again, if there were some exploitable flaw in qvm-copy or
qvm-open, then there could be a risk. Otherwise, if the malware is
triggered when it is opened, then opening in an offline disposable seems
a good option.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
