I’m looking for a clean and secure way to store data inside one VM (let’s call it data-vm) and allow other VMs to access this data, with different levels of access depending on the VM — for example:
Some VMs should have read-only access
Others should have read/write access
The main idea is to centralize shared data in one place, without duplicating it across multiple qubes, while keeping access tightly controlled.
I know that the Qubes native way to transfer data is using qvm-copy or qvm-move, but this can be time-consuming and results in multiple copies of the same file, which I’d like to avoid.
So far, I’ve considered:
NFS: Setting up an NFS server inside data-vm and mounting it in other VMs, using export options to control permissions.
Before I go too far with this, I’m wondering:
Are there any better or more Qubes aligned approaches for shared access to files?
How can I secure the setup and enforce per-VM access controls e.g. preventing write access for read-only VMs?
Is there a way to implement shared folders that respect Qubes security boundaries?
How do you handle project folders or shared documents securely between multiple qubes?
I’d love to hear about your solutions, setups, or ideas!
Here are the outlines of a possible solution–you’ll have to do quite a bit of research to flesh this out. A lot depends on how much space you need for this stuff. And you probably won’t do exactly this but I hope it gives you ideas.
You could create an AppVM and be sure to give it plenty of storage.
Inside that AppVM you can create a large file full of nothing in particular. You can then mount it as though it were a drive and format it.
You can use losetup (which will require sudo) to make the file an apparent block device that dom0 can parcel out. losetup has a read-only option. (I’ll spell that out in caps to make something clear: it’s lower-case LOSETUP, not IOSETUP.)
Then in dom0 attach it to the other vms. They will have to mount it.
One downside is that I believe only one VM will be able to accesss it at a time. The AppVM that owns the file/block device can be (at your option) either a dedicated “server” that never mounts the block, or one of the users. I’d go with the first but that’s just me.
(A much more complex version of this with encryption can be found if you search for “split-veracrypt” and in fact it will educate you on some of the commands you might need for this idea.)
I have been thinking about something similar but it seemed to me conceptually contradictory to the Qubes idea - isolation vs sharing.
What I mean is:
The data on data-vm is as secure as the VMs with write access. This means all VMs having any access to that data have the same level of security, as they are vulnerable to any “dirt” in data-vm. IOW, any attempt to isolate things from then on would be a security theater.
So, if the issue is convenience of data structuring, the whole thing can be done either with networking (incl. permission control) between data-vm and clients, or even in a single qube (faster, no network complications).
That’s why I quickly gave up on the whole idea.
Of course, I may be wrong, so I am also interested in knowing what others think.
I dont see the point in reinventing the wheel - use whatever standard
file store you are used to, and run it under qrexec, or Qubes
networking.
I favor ssh, but whatever works for you.
Some people think that this goes against the spirit of Qubes - I dont
agree. There are many cases where you want to share data within a
security domain, and you compartmentalise the qubes within that domain.
If you want help with a particular implementation, say what you want to
do in more detail.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
@unman your sync solution is great for backups. @AcidDemon the shared folders option is great if, for instance, you want an offline VM which can access, retrieve, edit, etc., documents or files from a networked VM.
Thank you all for the great input and ideas – I really appreciate the suggestions! I’ll look into everything more closely and will report back once I’ve decided which solution to go with and why.
To be honest, I was a bit worried at first that this might turn into a debate about how sharing data goes against the “concept” of Qubes. So I’m really glad to see the focus stayed on practical approaches. Thanks again!