Single File Storage for App VMs

General Discussion
1

In my personal experience with Qubes, one of the main inconveniences is file sharing and storage between qube AppVM’s. My ideal solution would be a main storage Qube (eg. “vault”) this qube would hold all the files for all designated AppVMs. And would interface with other AppVMs in replacement to their internal storage. For example, say I was was to download an image in a Qube called “work,” I would download it, but instead of downloading it somewhere in the “home” directory of “work,” it would download it in “vault’s” “home” directory. Then if I wanted to edit the downloaded image with an image editor in another qube, say “personal,” I would open the image in “personal” without moving it to “personal” (Like viewing files on a mounted block device). Then when I was done editing, the image would automatically save back to the “vault” qube. (I hope this makes since)
This has several benefits:

  • The storage space required for each qube would be less.
  • All files will be in one spot, not scattered all over multiple qubes.
  • File transfer would be mostly unnecessary, since any qube could edit/view any file straight from the storage qube.
  • If any qube was to be compromised, you would not loose any files in that qube, because there would not be any files in it.
  • You would not have to move files back and fourth through many qubes, as they would never leave the main storage qube.
  • You would not have to have a lot of duplicate applications in multiple AppVMs just to edit or view a file (eg. you want to view multiple images but they are located in a VM without an image viewer. rather than move all the files to a VM with an image viewer, or Download another image viewer in that qube, you would only need one image viewer to view it straight from the storage qube.
  • I’m sure there are others I haven’t thought of yet.

I’ve found a few ways that work, like a SMB server in the storage qube, but then if anyone has access to any VM, they have access to all your files. is there a way to temporarily mount a qube, like a block device? Or is there another way? I’d like to be as secure as possible.
What are Yall’s thoughts?

2

This is doable. I do something like this but with an added layer of complexity: I pass around veracrypt containers. One qube actually “owns” the containers. It (and dom0) hand a container off to another qube, which decrypts it. Then the decryptor qube (and dom0) hand it off to the qube that actually wants to access the data.

You don’t need quite that much, obviously, but you could create unencrypted containers on one qube (or have them be on a NAS that qube has access to), and pass those around in a similar way (no decryptor in the middle).

Disadvantage: Only one qube at a time can access a particular container.

Since I didn’t do exactly what you’re looking for but I came close, I can try to point you in the right direction. The first step, of course is to create the container, so I’m going to give you a bit of homework. Create (or pick an existing qube to serve as) a storage qube, and create a blank file on it of some size. You should then be able to use losetup on that qube to create a device, then mount it as if it were a drive. (This is all standard linux–and I probably have some details wrong in this description.) You should be able to write a file to that “drive,” dismount it, remount it and still see the file. (For this purpose just “touching” it should be sufficient to create it.)

Once you have a block device that’s really a file on whatever qube you’re using for storage, you should be able to do a losetup on it, have dom0 see it, and then have dom0 attach it to some other qube. There, you can mount it and read from and write to it.

You’ll probably want to automate a lot of this with shell scripts, if you get it working.

1 Like
3

@SteveC Okay, That sounds like it might do the job.
Thanks for the advice!

4

Suppose that the image file you download in work is malicious. You now have a malicious image file, which gets stored in vault. Since nothing is ever opened in vault, you don’t have to worry about the image file compromising vault or its contents. So far, so good.

But then, you say, you open the malicious image file in personal, which then compromises personal. We must now assume that all other files to which personal has access are also compromised, including all files in vault to which personal has access. So, even though vault itself is safe, since nothing ever runs in it, an unknown percentage of the files in vault are now compromised (potentially up to 100%, if a compromised qube ever has access to all of vault’s files). By design, you can’t do anything in vault, and every qube in which you can do things can be instantly compromised as soon as it parses any compromised file from vault, including fresh disposables. It is unclear, then, how much security we really gain from this model compared to more conventional compartmentalization and, importantly, whether the gain (if any) is worth the costs of setting all of this up and maintaining it.

My data is the same size whether I store it all in one qube or scattered across many qubes. Dividing it or consolidating it doesn’t change the total. However, it is true that each qube requires some dot files that take up a (usually*) small amount of space, so each additional qube does increase the overall size of a Qubes backup.

*(Web browser cache files, for example, can take up quite a bit of space and do seem like a waste to back up.)

That is, indeed, more convenient in some ways. However, if your qubes are organized intuitively (e.g., family, health, finances, work), then having each set of files in its respective qube is not necessarily a hindrance and can even be beneficial.

If your qubes are well-organized in the first place, then file transfers should already be mostly unnecessary, except in the case of disposables.

If a qube were compromised, it could effectively destroy all data to which it has access, including any data in vault to which it has access. Even if it’s only allowed to edit a file (not delete it), it can effectively destroy the data by blanking out the file or replacing the contents with gibberish (or ciphertext, as in the case of ransomware).

Moreover, a compromised Internet-connected qube could leak all the data to which it has access. If it has access to files in vault, it could send their contents to the attacker or upload them to a public place on the Internet for all to see.

Alternatively, a restrained attacker may opt neither to destroy nor to leak the data, instead altering it in subtle ways so as not to reveal that a compromise ever occurred (e.g., changing certain words or values in a document, email, or spreadsheet, which may only become significant at a later time).

Both the data leak and data alteration attacks could continue indefinitely as long as you don’t change your setup (e.g., because you don’t realize that a compromise occurred).

I believe this is the same as (3).

If your templates are well-organized, you should already not have to have many duplicate applications, except for very basic ones (e.g., terminal emulator, file manager).

I believe this part is fundamentally the same point as (3) and (5).

3 Likes
5

@adw I knew there were several holes in my “Ideal” setup, I just didn’t know if there was a workaround or precaution I could take so as not to compromise as much security. Which is why I wanted to get second opinions. I guess its as the saying goes, “Convenience is the enemy of security” you brought up a few more points I hadn’t thought of. However, with the way I have my Qubes configured, I could use something with similar functionality, though of course not at the cost of security. SteveC has offered a plausible solution, I think will work.
Thank you for your insight!

6

I am not sure what I did actually helps ADWs concerns. I’m still storing files in a place; that place is still being accessed by appvms (though mine are disposable), there’s still the potential attack that ADW describes of having one file infect all the others in a container.

@adw has certainly given me food for thought. He didn’t comment directly on my answer to you; I hope he does.

7

@SteveC isn’t that somewhat a problem for sharing files between any qubes? I guess the only difference would be all files vs a portion of files. I wonder if there’s a way to combat this?

8

Your case is a bit more difficult for me to comment on, since some of the implementation details are unclear to me, and it really depends on your goals.

I guess the key question is what effect the use of Veracrypt containers is designed to achieve. Presumably, the use of encryption is intended to achieve confidentiality in some way – but from what or whom? For example, if you keep these containers encrypted at rest whenever you’re not using them, then maybe that provides decent data confidentiality protection in the event that an attacker physically steals your machine while it’s running. If that’s the main threat you’re worried about, then maybe this setup provides sufficient value to you to keep using it.

On the other hand, if the goal is to protect the data in each encrypted container from the qubes that access it, then I fear we run into the same problem discussed above: A compromised qube can do whatever it wants with the data to which it has access. It makes little difference whether the container is decrypted in the qube for a short or long period of time.* An attacker need not sit at the keyboard waiting for you to decrypt. You should assume the bad stuff will happen automatically as soon as you decrypt the container in a compromised qube.

*(Except, perhaps, for long-running activities like ransomware encrypting large quantities of data and cryptominers continuously running.)

You would have to grant each qube access to only the select file(s) it should have at the time. For example, when you open/edit a file in a disposable, that disposable has access to only that file, not all the files from the source qube.

9

This answers my question. Basically, it provides no protection whatsoever against the hazard you were warning LinuxUser of. s/he seemed to think my method somehow would. I doubted that to be the case and you confirmed it. Basically an infected file can hose every bit of data on the system.

One thing I do is to never access the files on a VM that is connected to wifi (i.e., the internet). So a malicious file will have a hard time phoning home, if it needs to. Furthermore, because the VM that decrypts the container doesn’t have direct access to the system the containers are stored on, that’s another layer of difficulty for an attacker (depending on what he’s trying to accomplish).

The accessing VMs are disposables…which may or may not help. If the infected file simply attacks the accessing system, the infection dies when I shut the disposable down; the next time I access that VM, it’s clean at least until I open that particular file again. If it infects other files as well…well, then we have the scenario you are talking about.

The containers do secure data from people hacking into (or getting hold of) the system they’re stored on (which is not my qubes box).

10

@SteveC First of all, just for the record, I’m a he. :wink: Second, I was thinking your method would at least fix the problem of all the qubes having 24/7 access to the same file source. It seems to fix all/most of the security issues, except the malicious file problem. I couldn’t find a solution to that.

11

@adw @SteveC In your opinion, would a “trusted” file source solve the infected file problem? Say that you had two containers/storage qubes, a trusted, and an untrusted. Both would have no access to any network so as to minimize risk. any file to be stored, would first be sent to the “untrusted” storage, and would there somehow be “tested.” I’m not quite sure how this would be done, maybe disposables? Once considered “safe” the files would be moved to the “trusted” storage. and the trusted storage would be shared with the other qubes. This way theoretically, there would be no chance of malicious content entering your AppVMs. I know this would be very inconvenient, but it’s just an idea.

12

The problem is that no such reliable testing procedure exists, except for cryptographically-authenticated data.* The best you can do is probably some kind of advanced antivirus/malware scanning, but that can never conclusively prove that a file is non-malicious, since it’s always possible that the malware is sufficiently new and advanced that your scanner cannot detect it.

Disposables are not a panacea. If you parse a malicious file in a disposable, the disposable can be compromised. Then, when the disposable (or the relevant software running in it) tells you that the file is non-malicious, it may be lying to you. Being ephemeral does not give disposables any other special powers beyond regular app qubes.

*For example, the Qubes backup system uses authenticated encryption, which is what makes it possible to move data from a less-trusted place (e.g., cloud storage) to a more-trusted place (e.g., dom0, your vault qube) securely, but this relies on the fact that you know the passphrase used for encryption and authentication.

Similarly, the Qubes update system allows data to move from a less-trusted place (e.g., a random repo mirror) to a more-trusted place (e.g., dom0, your templates) securely, but again, this relies on the fact that your system already has trusted signing keys so that it can verify the signatures on updates.

In both cases, there’s still no guarantee that the data is non-malicious. (You can include malicious data in your backups. A rogue developer can sign a malicious package.) The only guarantee is that the data is authentic.

13

@adw Those are very good points. How do you go about addressing this issue in your setup?

14

I just try to follow the intended design and compartmentalize different aspects of my digital life in different qubes (or groups of qubes). Rather than having a single offline qube with all of my files, I have several qubes for different areas of my life, some of which are offline and some of which are network-connected. If I download a file in an online qube that I need to keep, I either keep it in that qube or, especially if it’s a disposable, transfer it to the appropriate related offline qube. I don’t regularly move files between qubes associated with different areas of my life.

If you haven’t already seen it, you might be interested in this:

15

Ah, okay I misunderstood you.

Yes by parceling things up into multiple containers you can somewhat compartmentalize. However as ADW pointed out you wouldn’t gain much advantage in storage, if files A, B, and C are only every used by Qube 1, wile D, E, and F are used by Qube 2, then keeping A, B, and C on Qube 1 and D, E, and F on Qube 2 is no worse than keeping A-F on some other Qube (in two separate containers) and connecting those containers to the two Qubes. (You don’t want to put them all in one container, otherwise only one of the two qubes can be doing something meaningful at a time.)

One thing disposables would do for you in case of a malicious file is possibly slow the infection from spreading between containers, if you shut the disposable down before switching from one container to the next, it can’t infect the second container.

My main motivation for doing this, actually, is that it lets me keep my files on a NAS. The NAS can then back up the containers. The NAS never decrypts the containers, so basically, if someone manages to break into it. they get nothing useful. And using disposables disciplines me to avoid having files pile up in odd places, scattered all over the QubesOS system.

16

@adw Okay Thanks.

17

@SteveC That makes since, Thanks.

18

This may be a bad idea, so correct me if I’m wrong, but what about some form of encrypted cloud storage. I think this would solve pretty much all of the mentioned security issues. And many cloud services have auto backups. What do y’all think?

19

It really depends on your goals and what sort of implementation you have in mind. For example, should the data be confidential from the cloud storage provider? If so, then you should encrypt it locally before uploading it. Are you worried about losing access to data in the cloud (e.g., storage provider outage, account closed without warning)? Then you’ll need a local copy anyway. How exactly will the cloud storage be used? Will every qube that needs access be network-connected and work with the files in the cloud? Then it’s unclear why they need to be separate qubes.

Remember, “the cloud” is just someone else’s computer. You’re just accessing it via the Internet instead of locally. It doesn’t fundamentally change the fact that a qube is accessing data stored outside of itself or the fact that the data may be shared among multiple qubes (and all that entails, as we discussed above).

20

I completely understand frustrations caused by loosing conformity. I had them for so long too. But had my priorities and now immensely happy I changed my computer using habits! The most important one - I don’t spend that much time in front of the computer doing meaningless things, because it would took me too much effort to do that. I’m using it just for what I really need. So, when I sum up, I’m much more efficient now.

Main thing (should’ve) happened - Qubes changed me, not me the Qubes.