I want to setup a share folder all the appVms can access seamlessly.
Is it possible to setup something up like this without opening a security hole?
If so, how’s it done?
Why would you do such a thing?
You can share files between qubes using the qvm-copy/qvm-move commands and their equivalent in the context menus of nautilus or thunar.
Having a “share folder” breaks compartmentalization in spirit and creates a circumstance that makes human error (sharing something by accident with a compartment that shouldn’t have access to it) more likely.
2 Likes
There are some files a frequently have to reference.
The copy/move between appVms is too much friction.
Plus they get out of sync with each other.
I’m looking for a way to streamline, while maintaining security.
If I had a read-only share folder, that all the other appVms could access, and then have a read/write access appVm to edit/change the share folder, it would seem I would maintain security, while giving seamless access to the other appVms.
The question is how to set something like that up?
1 Like
What you want is of course technically possible. It involves running a server of some kind in your “share folder” qube and then configuring sys-firewall and all the client qubes to be able to connect to it. It’s all documented.
However I still think it’s “wrong” and there is probably a better solution.
Of course it depends what you mean by “frequently have to reference”… I struggle to see a scenario that isn’t easily solved with qvm-copy/move, qvm-open-in…, copy&paste
2 Likes
I have to ref, multi times an hour. I’ve tried the copy/move… too much friction.
What better solutions would you recommend?
1 Like
2 Likes
I was going to post the same link as @fsflover
There are some good arguments for skipping this idea. One is that you will lose so much compartmentalized security that you might as well do everything in one VM. Why bother having separate VMs if you are going to effectively “rejoin” their file systems?
too much friction.
2 Likes
I’m afraid, you’re using Qubes with wrong intentions. Most of this, you can do with other Linux distributions I guess. But to your question:
not the best thing in case of Security, Privacy, blabla… but I’m using a share drive on my local NAS, where all qubes have access on it, if needed.
1 Like
I’m not convinced they can’t both be had… with right architecture, and scripting automation.
What is your use case? What is your threat model while using a shared folder between two qubes? Why can’t you do it in the same qube, while compartmentalizing everything else?
1 Like
Maybe… but I think this issue touches on some very universal principles of security. So much care goes into making sure that VMs are truly separated. It’s like building a secure castle with an iron gate and moat… only to later think “but it would be so much more convenient if I had an easy way in and out… just for me!” Of course, we know how that usually ends. What your describing is a kind of backdoor.
2 Likes
3 Likes
I could. But that would still require some appVm copy operations, that are unavoidable with non-networked qubes. Keeping compartmentalized, without the friction is the goal.
1 Like
Or a door with a gatekeeper that seamlessly waves you thru, but nobody else.
1 Like
Yes… that’s the ideal.
1 Like
You probably didn’t understand me. Why can’t you do everything related to folder sharing in the same qube?
One man’s friction is another man’s traction. Can you think of examples of security that are frictionless compared to no security? It seems that friction is part of it. Not excessive friction… but some?
There was discussion about using rsync to handle the connectivity which was received more favorably by the lead developer. Perhaps there is a way to achieve similar functionality without actually “file sharing”. Apparently file sharing has a much bigger impact on security than other forms of inter-VM transfer.
I was thinking it might be useful to have a secondary form of GUI for qvm-copy-to-vm. Instead of right click → copy to vm, maybe have a folder that allows properties to be set that “link” it to another VM. Whenever a file is dragged to it, the file is stored in the folder locally and copied to a given VM via the secure copy method. That would mimic file sharing without actually file sharing.
How about, given that this is likely to shoot me in the foot - anyone have a clearcut method to enact it? I absolve them of responsibility in advance.
If any of us knew more about the reason for this circus, perhaps a path could be advised that doesn’t lead thru this objectionable area? Are you for instance a developer with specific requirements about compartmentalization and the control over network access of a Qube but wouldn’t another VM solution like KVM or Virtualbox be able to perform instead?
Are you looking to create a “one VM can read/write, all the rest can only read” type of share, or do you want all participating VMs to have read/write capability?
If the former and assuming LVM thinpool…I can think of a scripting approach that’ll work.
You create, then attach a long-living read/write LV volume to a “publisher” VM, (you script attaching to that VM after each VM startup). That publisher VM aggregates all the data to be shared.
Your script would also create a read-only snapshot of the read/write LV after shutting down the publisher VM each time. That snapshot will have an unchanging name or a discoverable pattern.
Through additionalal scripting, each VM that needs the data would get it’s own locally-named snapshot of that publisher’s read-only snapshot, creating/destroying it on each startup/shutdown.
Using a snapshot of snapshot decouples the startup/shutdown of the publisher vs. the startup/shutdown recipients, as the middle snapshot can be removed without requiring the recipient VMs lose their copy. I think the snapshot-of-snapshot can also be set to be automatically discarded when no longer in use.
I does mean, similar to VM templates volumes, there’s a delay in delivering changes: you only get the changes made by the publisher after a) the publisher shuts down (syncronizing the read/write volume into the read-only snapshot) and b) the recipient VMs are started up (or restarted if they were already running).
Brendan