(feature suggestion) shared folders (perhaps over qrexec?)

[tonsimple]

Basically what it says on the can.

Right now, I'm using a separate VM with smb server to share folders between several VMs (including a windows one), but it

1. has unpleasant overhead
2. smb has a lot of features that are, well, not really needed for this usecase and are just extra attack surface/general drag
3. the VMs have to share a firewallvm/proxyvm

inspired by reading about https://github.com/QubesOS/qubes-app-linux-usb-proxy while trying to come up with a way to share a folder with a qube that is supposed to have direct connection to netvm (thus not connected to the proxyvm which the smb hosting one is connected to)

[cyrinux]

Hi,
What about this?

https://groups.google.com/forum/m/#!topic/qubes-devel/rCc20BTZ9co

[cyrinux]

Hi,
What about this?

https://groups.google.com/forum/m/#!topic/qubes-devel/rCc20BTZ9co

[tonsimple]

@cyrinux
Thanks!
Looks interesting.
Though comments by Vít Šesták (particularly about inode number guessing) worry me a mite.

Also, I don't quite understand what "The home directory of the destvm should be readonly accessible in the given directory in the srcvm" means, I guess I'll ask in that project's github issues.

[tonsimple]

@cyrinux
Thanks!
Looks interesting.
Though comments by Vít Šesták (particularly about inode number guessing) worry me a mite.

Also, I don't quite understand what "The home directory of the destvm should be readonly accessible in the given directory in the srcvm" means, I guess I'll ask in that project's github issues.

[jpouellet]

Can you help me understand the intended use case?

"Shared folders" in every way I've seen implemented are dangerous to some degree (in any case more than qvm-copy/move-to-vm), so I'm curious if perhaps the root motivation can be satisfied in another manner. I really don't see what purpose it serves, but you're not the first one to ask for this or hack together a solution, so there must be something I'm not seeing...

[jpouellet]

Can you help me understand the intended use case?

"Shared folders" in every way I've seen implemented are dangerous to some degree (in any case more than qvm-copy/move-to-vm), so I'm curious if perhaps the root motivation can be satisfied in another manner. I really don't see what purpose it serves, but you're not the first one to ask for this or hack together a solution, so there must be something I'm not seeing...

[adrelanos]

Does https://www.qubes-os.org/doc/copying-files/ work for you?

---

Otherwise, let me throw in a big hack. Perhaps ssh over qrexec and then using sshfs.

[adrelanos]

Does https://www.qubes-os.org/doc/copying-files/ work for you?

---

Otherwise, let me throw in a big hack. Perhaps ssh over qrexec and then using sshfs.

[tonsimple]

@jpouellet
Say you're downloading a large (like, 4 TB large) file (torrent or whatever) and you can't commit 4TB both to VM that is "internet-facing" and the VM that is supposed to store/process/etc the file.

Right now I'm doing a samba share, but samba is hugely unpleasant in ways I outlined in original post.

I realize that shared folders add attack surface and complexity no matter how you slice them.
But I would prefer things that add less of that than "a dedicated SMB server"

@adrelanos
Technically copying files would work if I could commit enough storage to both the VM that "does the downloading" and the VM that is "supposed to eventually handle/process/etc. the file"

SSHFS is definitely a viable alternative at least in the sense that it's probably less complex than a "fully grown" SMB, but point 3 and to some extent point 1 from my original post would still stand.

Ideally, the shared folder solution would not need to have the "host VM" (source of share) and "destination vm" (the machine to which the folder is shared) to have same proxyvm/firewallVM (so that the machine doing the "processing" of the file could be left with no "proper networking" beyond the single folder share)

[tonsimple]

@jpouellet
Say you're downloading a large (like, 4 TB large) file (torrent or whatever) and you can't commit 4TB both to VM that is "internet-facing" and the VM that is supposed to store/process/etc the file.

Right now I'm doing a samba share, but samba is hugely unpleasant in ways I outlined in original post.

I realize that shared folders add attack surface and complexity no matter how you slice them.
But I would prefer things that add less of that than "a dedicated SMB server"

@adrelanos
Technically copying files would work if I could commit enough storage to both the VM that "does the downloading" and the VM that is "supposed to eventually handle/process/etc. the file"

SSHFS is definitely a viable alternative at least in the sense that it's probably less complex than a "fully grown" SMB, but point 3 and to some extent point 1 from my original post would still stand.

Ideally, the shared folder solution would not need to have the "host VM" (source of share) and "destination vm" (the machine to which the folder is shared) to have same proxyvm/firewallVM (so that the machine doing the "processing" of the file could be left with no "proper networking" beyond the single folder share)

[jpouellet]

Ideally, the shared folder solution would not need to have the "host VM" (source of share) and "destination vm" (the machine to which the folder is shared) to have same proxyvm/firewallVM (so that the machine doing the "processing" of the file could be left with no "proper networking" beyond the single folder share)

This is achievable with ssh over qrexec. I use this on my Qubes server. Create a qrexec service in the target VM which starts sshd in inetd mode (sshd -i), and then use ssh '-oProxyCommand=qrexec-client-vm other-vm-name local.SSH'. It should be noted that from a security perspective this is equivalent to qubes.VMShell* and effectively 100% eliminates any meaningful trust boundary protecting the target VM from the source VM. It is perhaps even more dangerous than qubes.VMShell since by default ssh exposes a source domain pty to manipulation by the target domain, which qubes.VMShell avoids. If this is really what you need, then maybe give it a try.

However: This completely violates the Qubes security model. If you are in the situation where you really need to be sharing such giant data across VMs, then perhaps using a single VM with the tools of both installed makes much more sense. Unless someone can provide evidence that users really require such functionality and are currently doing something more dangerous than this, then I believe it would be a design mistake to make this functionality easily available.

[jpouellet]

Ideally, the shared folder solution would not need to have the "host VM" (source of share) and "destination vm" (the machine to which the folder is shared) to have same proxyvm/firewallVM (so that the machine doing the "processing" of the file could be left with no "proper networking" beyond the single folder share)

This is achievable with ssh over qrexec. I use this on my Qubes server. Create a qrexec service in the target VM which starts sshd in inetd mode (sshd -i), and then use ssh '-oProxyCommand=qrexec-client-vm other-vm-name local.SSH'. It should be noted that from a security perspective this is equivalent to qubes.VMShell* and effectively 100% eliminates any meaningful trust boundary protecting the target VM from the source VM. It is perhaps even more dangerous than qubes.VMShell since by default ssh exposes a source domain pty to manipulation by the target domain, which qubes.VMShell avoids. If this is really what you need, then maybe give it a try.

However: This completely violates the Qubes security model. If you are in the situation where you really need to be sharing such giant data across VMs, then perhaps using a single VM with the tools of both installed makes much more sense. Unless someone can provide evidence that users really require such functionality and are currently doing something more dangerous than this, then I believe it would be a design mistake to make this functionality easily available.

[tonsimple]

@jpouellet
It seems to me that this approach would possibly be more of a "risk" than having source VM "doing samba" to share a folder with "downloader" (with some basic firewall rules preventing direct internet access for the source VM)

So far, SSHFS seems by far the nicest of options.

[tonsimple]

@jpouellet
It seems to me that this approach would possibly be more of a "risk" than having source VM "doing samba" to share a folder with "downloader" (with some basic firewall rules preventing direct internet access for the source VM)

So far, SSHFS seems by far the nicest of options.

[jpouellet]

Right, but then why have multiple VMs in the first place? If doing so eliminates the trust boundary between the VMs, then you gain no security by having separate VMs, so why use separate VMs at all? Do you need to use multiple tools on the same large dataset which are only available on linux XOR windows or something?

I don't see the benefit to further decomposition in this case -- and I say that as someone with an absurd number of VMs myself.

[jpouellet]

Right, but then why have multiple VMs in the first place? If doing so eliminates the trust boundary between the VMs, then you gain no security by having separate VMs, so why use separate VMs at all? Do you need to use multiple tools on the same large dataset which are only available on linux XOR windows or something?

I don't see the benefit to further decomposition in this case -- and I say that as someone with an absurd number of VMs myself.

[tonsimple]

@jpouellet
Well, I suppose samba/SSHFS maintains some security boundary (adjusted for issue of exploits in SMB (lol ;-) ) or (in case of sshfs) SSH.

An "ideal-hypothetical" shared folder solution would be some daemon that doesn't need to run as root and can be run as separate user (which should in theory limit the amount of mayhem if "something happens") but I'm not sure that's possible given current qrexec mechanisms.

[tonsimple]

@jpouellet
Well, I suppose samba/SSHFS maintains some security boundary (adjusted for issue of exploits in SMB (lol ;-) ) or (in case of sshfs) SSH.

An "ideal-hypothetical" shared folder solution would be some daemon that doesn't need to run as root and can be run as separate user (which should in theory limit the amount of mayhem if "something happens") but I'm not sure that's possible given current qrexec mechanisms.

[marmarek]

IIUC the problem is:

1. You have huge file downloaded from the network
2. You don't want the tools used to parse the file to communicate with the network

I think with the currently available features, solutions closes to those requirements is:

1. Create fresh AppVM (ideally DispVM, but it isn't possible to adjust its size, at least right now)
2. Start it with network connected
3. Download the file
4. Disable networking for this VM (set netvm to "none")
5. Process the file.
6. Do not ever connect this AppVM to the network again, if you want to process another file, use new AppVM.

[marmarek]

IIUC the problem is:

1. You have huge file downloaded from the network
2. You don't want the tools used to parse the file to communicate with the network

I think with the currently available features, solutions closes to those requirements is:

1. Create fresh AppVM (ideally DispVM, but it isn't possible to adjust its size, at least right now)
2. Start it with network connected
3. Download the file
4. Disable networking for this VM (set netvm to "none")
5. Process the file.
6. Do not ever connect this AppVM to the network again, if you want to process another file, use new AppVM.

[andrewdavidwong]

Sounds like a similar use case to #2486 (comment).

[andrewdavidwong]

Sounds like a similar use case to #2486 (comment).

[holiman]

I also would like this feature, but for a different usecase. I use different VMs for development, e.g one for golang, another VM that builds docker images, and a third for npm/electron and javascript things. I would like to be able to have a shared disk area that I can use for git repositories, instead of having to qvm-copy entire repos between the different VMs, and also not have to set up gpg-split in each vm (I use gpg-split to sign git commits).

I'd want to do e.g electron-dev in a, build docker image in b and commit/sign/push in c.

[holiman]

I also would like this feature, but for a different usecase. I use different VMs for development, e.g one for golang, another VM that builds docker images, and a third for npm/electron and javascript things. I would like to be able to have a shared disk area that I can use for git repositories, instead of having to qvm-copy entire repos between the different VMs, and also not have to set up gpg-split in each vm (I use gpg-split to sign git commits).

I'd want to do e.g electron-dev in a, build docker image in b and commit/sign/push in c.