Best Way To Setup A Global Share Folder?

General Discussion
21

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.

3 Likes
22

THANKS! That’s what I was looking for.

23

It’s pretty straightforward but if you need help, post here.

1 Like
24

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:

  1. A qrexec service (that accepts the source folder as argument) to be deployed in qube B, which starts an RPC daemon that serves (2) via 9p.
  2. qube A mounts the file system using the builtin 9p kernel module, having it connect to the qrexec service (1) and, once established, mounts the file system served by qube B via qrexec.
  3. (optional) perhaps a simple GUI program to establish the mount from qube A, which also displays prior mounts, and maybe attempts to save these mounts so they run on boot.

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:

  1. Exploitable bugs in the implementation of the “mount share” qrexec service.
  2. Data leaks arising from bad user diligence in allowing or denying access to a specific server folder to be mounted in the client qube.

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.

25

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:

26

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.

3 Likes
27

Wow, that’s like wearing a mask and then making a big fat hole where the nose is to make breathing more convenient.

  • There is currently no way to control which folders of the server qube can be requested by client qubes. In principle this should be doable because diod can export only a subtree of any file system hierarchy, but the next point needs to be addressed first.
  • The connection remains open after unmounting. This means that the client VM can in principle continue to access resources from the file system exported by diod before the unmount happened.

lol indeed

I get (maybe) qubes-sync. But this? Why not put everything in one qube and call it a day? Or just stop using Qubes OS / compartmentalization?

If qube A is compromised, the attacker will have access to EVERYTHING in qube B !?!?!

I get this is a first version and you want to make it that only dedicated folders are accessible. But I would NEVER consider using anything like this without it being audited to death and accepted by the core team.

1 Like
28

Yes, this is a first version. Here is a to-do list for which I would gladly take contributions:

  • Permission system to allow certain folders to certain VMs (the argument in qrexec is sanitized, rendering it useless for that)
  • Persistent notification on tray that indicates a specific folder is exported to a certain VM
  • Performance improvements (large mounts from network shares can be very slow)
  • Security hardening (make check was disabled in the specfile because there are some issues I don’t know how to fix, sadly)
  • UI for mount clients to configure certain mounts to be mounted upon start / list existing configured mountpoints and statuses and open file managers to these mountpoints

Note that Plan 9 (the implementation choice) file system clients and servers are used widely in virtualization and are considered relatively safe for use, although not sure if that applies to the Qubes OS use case. This would be no different from allowing SFTP access between VMs, except there is no encryption overhead (that needn’t be there).

29

I have always used good old NFS for this purpose. It was designed to share a filesystem between separately administered machines on a network, which is what Qubes looks like. It has all the controls required and is well documented. I use a small external (to Qubes) partition, a loopback device within Qubes works as well. A directory can be used with “subtree-check” in the export. Best to use a contained partition to minimise chance of leakage. Quite easy to set up qrexec on R4.0 (not sure about 4.1). The server Qube probably should not do anything else and have no network as all its TCP ports will be accessible to each client.

S = name of server Qube. C = name of client Qube(s).

in dom0: add line(s) to /etc/qubes-rpc/policy/qubes.ConnectTCP: C @default allow,target=S

in S’s template ensure rpcbind and nfs-kernel-server (Debian) packages are installed [rpcbind and nfs-utils on Fedora]
On Debian-11 you need to unmask rpcbind: systemctl unmask rpcbind

in S rc.local: Create /etc/exports here (or in above) assuming your shared device is mounted in /mnt:
echo "/mnt 127.0.0.1(rw,insecure)" >/etc/exports # “insecure” needed as sport > 1024
systemctl start rpcbind nfs-server

in each C rc.local:

        qvm-connect-tcp ::111
        qvm-connect-tcp ::2049
        mount localhost:/mnt /rw/share # or wherever shared folder should appear

OK, shoot me down!

[ed] Note dom0 will attempt to start the server automatically when the first client is started during bootup - if there is a problem with the server then you are in for a surprise! The screen fills with Qubes status alert boxes as dom0 goes into an infinite loop trying to start the server… did post this on github, expect could be 5 years till it bubbles to the surface.

30

Please educate me:

What use cases cannot be reasonably accommodated using the build in file copy/move and copy&paste functionality?

And if such a case exists, why isn’t unidirectional sync enough?

What workflow would be spread over multiple qubes, yet at the same time require read/write access to the same files?

I didn’t push the OP to explain their use case because they might not be comfortable doing so. However, I see now multiple long-term users pile on and no one has spend any energy on explaining the use case.

I’m not looking for a “fight”, I want to understand.

3 Likes
31

I have a use case that may not be the same as OP’s.

I have a file server, attached to a specific VM, where I archive stuff that comes from the Web. For obvious reasons, since the file server has more than just that class of file, I don’t want to mount the file server on the Web browsing VM (otherwise total compromise of the Web browsing VM means full access to the file server’s whole contents). Thus the file server is attached to that specific VM in question, which I’ll call the media server VM.

So what I’m doing now is mounting on my browsing VM a subfolder of the media server VM. That way I can directly save archival material into that subfolder.

Prior to this setup, I was suffering through saving locally on the VM, then having to have these long-ass sessions where I organize the files by (1) qvm-copying them from Web VM to media server VM (2) drag-and-drop copying them from media server VM to file server. This was exhausting and completely discouraged actually organizing the files.

Now I can just use the file chooser on my Web browser to select the exact folder I want to drop my archival download in. All archival materials end up in their final destination — their corresponding folders on my NAS machine.

HUGE difference in terms of usability.

Is this riskier than copying files manually?

Yes, I’d argue it is — right now there is no policy mechanism to prevent the Web VM from mounting “the wrong folder”, although in the future there will be. Furthermore, since we’re talking about complex protocols between VMs, there is always a possibility of a bug being exploited. The same is true for SAMBA and NFS setups that involve qubes.ConnectTCP by the way, the exact same way — my solution is just far less complex in both terms of code and configuration than something like SAMBA or NFS.

Is the current tradeoff worth it?

For me, it is. I can do something I could not do before, much more quickly, and with adequate risk tolerance (which will get better once the shared folders system asks for authorization to export a specific folder).

2 Likes
32

Soon:

image

See thread Design questions for the next steps of the Qubes shared folders service - #2 by Rudd-O

This code needs testers and reviewers!

33

Wow!

2 Likes
34

Well, technically, if they don’t pull out the pipe from their mouth, and then harden the other end with a mask, they got it!

35

Yeah… your notes mention:

Enable the ssh-setup service in the client. (This doesn’t exist as yet, but should check that ssh is installed and forwarder is enabled).
systemctl enable qubes-ssh-forwarder.socket
systemctl start qubes-ssh-forwarder.socket

File qubes-ssh-forwarder.socket has in it
ConditionPathExists=/var/run/qubes-service/ssh-setup

What exactly do I write in the file /var/run/qubes-service/ssh-setup?
And how (syntax?)

I’m guessing I have to set it root ownership like this file?

-rw-r–r-- 1 root root 0 date time qubes-update-check

I’m using R4.1 with debian-11-minimal

Thanks!

36

sudo touch /var/run/qubes-service/ssh-setup

And how (syntax?)

I’m guessing I have to set it root ownership like this file?

-rw-r–r-- 1 root root 0 date time qubes-update-check

Not tested with that config, but worth testing.

37

Even though it can be done, should it be done? Has an extent of condition been done to assure it can be used in an enterprise environment?
Probably a good exercise if determining the potential threat surface this can create is part of the answer.
I’ll err with the group on the conservative side.
If this thread is for a single user system then great. But why go through the effort or setting up a compartmenatlzed system when it seems all these questions are an attempt to downgrade security to make a M$ box with VMware. Why use Qubes, just get a M$ box and have at it.
With just the history of attacks on NFS, samba, etc. and just having uncontrolled access by a variety of users in an enterprise setup this should really be a red flag.

38

“It won’t happen to me”
“I know what I’m doing”
or… to create a honeypot.

For the sake of new Qubes users as must-a this and similar topics should have be flagged with:
[WARNING: Against Qubes OS Basic Principals]

How I see it, no one is born conservative. For me, it’s a sign that the one became responsible.

39

There is such great trust in this system.
How many people can tell when they’ve been hacked?
NFS is not encrypted.

Just some 1st order considerations that a new user may not consider:

https://www.netspi.com/blog/technical/network-penetration-testing/linux-hacking-case-studies-part-2-nfs/

40

another usecase:
After downloading 1-2Tb with my Torrent-qube, I move the payload to storage. Yet 200-250Gb still remains in .cache, unneeded (especially in the backups).
I could delete the content of .cache, or I could split torrent-qube up into torrent-disposable that stores the payload in torrent-payload-qube.
sure, if torrent-disposable gets compromised they may also have access to torrent-payload-qube…, but the same would apply to the orriginal case where it’s in one qube.
[edit] or better: let torrent-disposable store the unfinished payload on a temporary-storage-qube on a faster SSD, and have it moved to download-finished-storage-qube on a slower but bigger secondary storage.
(or does this method somehow expose all other qubes?)

another usecase:
Instead of having one email-qube, split it up into 3 as explained by @unman:

  • disposable mail fetcher
  • qube where mails are stored/processed without network
  • disposable mail sender

An attacker would have to compromise either disposable fetcher or sender to gain access to the emails… but he has to do that all in the short time the disposables are running.

This is under the assumption that sshfs does not expose all qubes/dom0 (which I dunno).