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.
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.
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?
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.
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.
Or a door with a gatekeeper that seamlessly waves you thru, but nobody else.
Yes… that’s the ideal.
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
While all other replies in this thread are right about questioning whether this really is necessary: if you feel confident that you know what you are doing you should have look at GitHub - unman/qubes-sync: Simple syncin between qubes over qrexec.
unman is also on this forum if you should need any “first-hand” help with this.
Again, keep in mind that nobody in here is just against your approach for the sake of being right. Instead, we tend to question every usage scenario in order to make it more secure. If you feel comfortable with sharing how you use Qubes and what exactly you need this functionality for it could probably help in order to understand whether file sharing is really the best option for you.
THANKS! That’s what I was looking for.
It’s pretty straightforward but if you need help, post here.
I think what would be extremely useful would be a “mount folder from qube B into qube A”, complete with qrexec permission dialog. I know I would use it all the time. This would probably come in the form of two parts:
Note that such an implementation would then be compatible with GVFS and KIO, so applications would transparently access folders and files from other qubes that have already been authorized by the qrexec subsystem.
FUSE-SSHFS is, sadly, not it, because it requires SSH keys, an SSH daemon, and it’s just crap to set up. I have yet to see a FUSE file system that is adequate to retrofit for the purpose, and (having been a contributor to zfs-fuse myself in my younger years) I do dread writing the FUSE code from scratch, in particular to get the code correct so as to avoid data corruption. I think FUSE is a non-starter here.
I would in fact be willing to fund the development of this component, and also work together with the person leading this project.
And, yes, I know it’s likely that there are security risks associated with this client/server model between qubes, and that we should just have files for purpose X be used only on qube X, and files for purpose Y be used only on qube Y… but I think (a) many of us just have a file server, likely mounted in one of our qubes, that we’d like to give other qubes access to a subset thereof (b) the design of this suggested project mitigates security risks substantially, reducing the compromise risk to two factors only:
EDIT: Eureka, I think? Instead of FUSE, perhaps 9p is the correct transport: v9fs: Plan 9 Resource Sharing for Linux — The Linux Kernel documentation — it’s widely supported and robust because it’s heavily used to do folder sharing in the context of virtualization, and it’s a dead-simple protocol that can go over any stateful connection transport, without the bullshit authentication and encryption overhead of something like SSHFS.
If you don’t need multiple AppVM access simultaneously you could set up an AppVM like sys-usb, create a image file(*.img), format it, copy your files into that file system, and then use qvm-block to attach that image file as a volume to the any other AppVM in read only mode.
With it read-only you might be able to refrence it from multiple places but I have no experience in doing that. Attaching a r/w volume in multiple places is simply asking for corruption.
More info here:
LOL I was bored so I did a thing:
That’s right, shared folders for Qubes VMs.
The documentation (README.md) is improving. Please be patient.
