More info: Data leaks | Qubes OS.
1 Like
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.
Ain’t that you are using mathematical terms?
What?
And no, that sort of notation is not exclusive to mathematics.
I’m just asking you about that.
@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.
2 Likes
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…
1 Like
got that. but if I add malicious files to the Vault, won’t my other files there be endangered?
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?
1 Like
no, your other file still be endangered
@Melly21 Sorry if I’m diverting your thread.
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.
When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
Related:
That’s probably overkill, but it’s personal preference.
Why is it probably overkill? Because of what I wrote here:
Also, there are probably some cases where you can safely funnel files from multiple qubes into a single offline storage qube. For example, if that offline storage qube is for storing completely untrusted, nonconfidential, replaceable files, then there’s probably no harm in funneling such files from multiple qubes into it.
Encryption isn’t a panacea. You still have to decrypt it sometime (unless you never need to access the data again), at which point it’s vulnerable.
It’s possible that malware could exploit a hypothetical side channel vulnerability. For example, an attacker could theoretically use the CPU cache to exfiltrate data from a compromised offline qube to sys-net, then anywhere over the internet.
If you truly never download anything, then your entire machine is permanently offline and air-gapped, in which case you mainly just have to worry about physical attacks (e.g., theft, coercion, evil maid) and emanations (TEMPEST-type stuff). But it’s doubtful that your machine is truly 100% offline. Browsing the web involves downloading bits to your machine over the internet. Updating Qubes involves downloading and installing things.
No, banks usually keep a half-year history of transactions. If you keep your history for longer, it does make sense to put your bank statements elsewhere. Otherwise I agree that there are many use cases where it makes sense to have fewer archival VMs.
Why is that significant when the contents of B are now at risk? That’s like saying, “Our top secret files are exposed, but at least the vault we stored them in is still in good shape!”
It doesn’t matter whether we call it B' or C. That’s just an arbitrary variable we use so we can keep track of which qube we’re talking about it. The reason it makes sense to call it B' is that it was created by cloning B. That makes it easier to keep track of the historical relationship between the two. But it’s just a matter of convenience; nothing hinges on the notation.
This only works while your vault is empty. As soon as you start actually using the vault and filling it with important confidential data, the scenario I described obtains. What good is a vault you can never use without wrecking your system for using that vault?
Thanks.
Not that I know of. There are, however, methods for securely transferring data from less trusted to more trusted locations. The Qubes backup/restore system is one such method and was specifically designed to achieve that goal through defensive authentication of the encrypted backup file prior to any significant operation on that file.
Because if you don’t reintegrate, you just end up proliferating less and less trusted vault clones. Remember, the scenario is:
Every time you try to “up transfer” a new file to the vault, you end up with another (less trusted) vault clone.
Agreed.
Ok, but then it’s unclear how this all works. If the idea is that there’s some way to “up transfer” without reintegration, then I think this will just turn out to be an illusion: Either there will not really be any “up transfer” in the end, or there will be some hidden reintegration.
Sure, but the devil is in the details. For example, some people think that if you have to decrypt a file/drive on a potentially-compromised OS, it’s significantly safer to leave it decrypted for only one minute as opposed to one day. But this is unlikely to make a material difference in practice. It’s unlikely that the hacker is just sitting there, watching and waiting for the opportunity to strike. More likely, malware will automatically perform some action when some set of conditions are detected or triggered, regardless of when or for how long the vulnerable window is open.
Some, sure, but you have to remember the context. The suggestion was that disposables could be used in some workflow to facilitate safe “up transfers.” Again, the devil is in the details, but here’s one way it might work:
- You start a new disposable.
- You copy/move the potentially-malicious file to the disposable.
- The disposable is now potentially compromised.
- You perform some operation on the file (e.g., convert to trusted PDF) in the disposable.
- You copy the desired file from the disposable to a vault.
If the disposable was compromised in step 3, then the operation in step 4 was too. The now-compromised disposable could have merely pretended to convert it into a trusted PDF, or it could have implanted malware into the output PDF, or anything else. It’s a compromised qube. It can’t be trusted. Then you directly copy a file from this compromised disposable to a vault. The interposed disposable isn’t doing anything for you. It’s just shifting the vulnerability around. You can add as many layers of indirection as you want, but unless you change something fundamental about this workflow, the result will be the same.
Depends. If you’re using a fresh disposable to download an untrusted file from an untrusted website, then it might be a bit pointless. The analogy that springs to mind is putting on a clean nitrile glove in order to pick up a piece of garbage and put it into your mouth. But still, it’s plausible that the disposable might have some benefit over using an already-compromised qube to do this.
It’s hard to say. For one thing, dispXXXX was probably running on a template with a lot more software installed than offline-slight-trust. But if dispXXXX was compromised, it’s quite possible that the file was too, in which case it depends on whether you open/run that file in dispXXXX.
This was already discussed upthread, but basically no. Merely storing a file in a qube doesn’t put that qube at much practical risk. It’s actually opening/running the file in a qube that carries most of the risk.
I’m not sure how you’d copy them except with qvm-copy (or equivalent), so I don’t know.
That shouldn’t meaningfully increase the risk. I suppose it’s theoretically possible that it might exploit some vulnerability in sha512sum, but that seems exceedingly unlikely. I’m not an expert, though.
See above for why interposing disposables often doesn’t provide the benefit people think it will.
1 Like
But this ignores the point I actually made. The important question is not whether the attacker gets access to six months versus six years of statements. Rather, it’s whether the attacker gets to transact on my account as if he were me. I care almost infinitely more about the latter than the former, so I’m fine, in practice, with storing unlimited historical data in a qube with transaction authority for the account that generated that data in exchange for the convenience of not having to deal with double the number of qubes.
But that’s just me. If you care enough to deal with double the number of qubes in order to make sure that an attacker who gains transaction authority over an account does not also gain access to old statements that are no longer available from the online account itself, then by all means. I just can’t imagine myself ever saying, “The hacker may have drained my account, but at least he doesn’t know how much was in it over six months ago!”
In other words: Of course I agree that there is a theoretical confidentiality gain from segregating data that an adversary wouldn’t otherwise have access to. I just don’t think it matters enough in practice to warrant the extra hassle.
The difference is that stealing your data is a simple process which is easy to automate, whereas getting into your bank account usually requires a two-factor authentication and precise customization to your bank. Even if you banking VM is compromised, it’s quite unlikely that you loose your money (and there is also a possibility to get it back by asking the bank, in principle). But the probability to leak all your data is very high.
In my understanding, even if you store your transaction data in the same offline qube where you store everything else, it’s much more secure/confidential than storing it in any online qube.
In the original paragraph you quoted, I said “barring multi-factor authentication outside of that qube.” But sure, I see your general point. In that case, though, I’m not so worried. After all, statements generally don’t have any data the can be used directly to cause significant damage. Otherwise, sending them through the mail would be/have been too risky. Probably the biggest risk of your statement falling into enemy hands is that they now know how big or small of a target you are!
But “bank” was just an example. If it’s a crypto exchange, for example, the blockchain transactions could be truly irreversible.
Ah, true, it could just be one. But still, I personally don’t see the benefits as outweighing the hassles. There are the file transfers, then the risk of opening files from different sources in the same offline qube, or the hassle of having to wait for a disposable/qvm-copy each time I want to open one. Plus, if I someday realize I want to transfer a file out of there to use it, I now have to worry about exposing all the other data. Just keeping the files in their originating trusted qubes seems like an acceptably minuscule security sacrifice for me that will almost certainly never make any practical difference.
1 Like
This depends entirely on what threat you are guarding against.
For example, if you had an account (of any sort) which you used solely to
funnel funds, there would be no threat from a hacker gaining control
over that account since it rarely has a positive balance.
But gaining access to 6 years of past transactions would be enough to
build a substantial case against you.
As always, Qubes provides the means, but it is up to the user to
determine what threat is significant for them, and how to use Qubes to
reduce that threat.
“that’s just me” is a great caveat - I wish more users would follow your
example when posting in this forum.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like