Best Way To Setup A Global Share Folder?

[enmus]

First, I’d like you to know that I extremly appreciate your time and your responsivness. I am sure all the rest or most of us do, too. Thanks for explaining in details your concept. The idea is absolutely clear and it indeed makes me rethink over and over again how I see and understand Qubes and why I use it at all. I hope you’ll find time to read my thoughts on it and eventually to respond again. As to a newbie, it would help me to test my comprehensions.

@unman

For example - I have a qube, offline and used to store some data. Let’s
call it the vault.

So, where the data came from? Generated in vault or/and came somewhere from outside? Which way the latter?

@unman

I set policies to deny any other qube from accessing the vault, or
writing to it.

This means the data was generated in vault then? Then, how to generate and store invaluable received emails, photos, videos etc in vault, for example?

But let us assume that your scenario was set for the data generated in the vault only. Then it makes full sense to me. But…

Unless I do something irresponsible like this (again convenience, ehm?), by doing that (which I of course wouldn’t), why it isn’t enough what we already have built-in? This is the most important answer I would like to get at the moment.

@unman

I set other policies so that information in the vault can only be copied
to one other qube.
Now I have (to some extent) limited the potential for a mistake in
using sensitive data in the wrong qube.

Now, I absolutely understand that your policies prevent picking up the wrong qube in the dialog box gui, but aren’t such wrongdoings out of scope of everything and everyone we interract with, not only of Qubes and vault? There couldn't be as many policies as needed to help us with this. Instead of setting the policy wherever we might pick up the wrong thing, wouldn’t be more effective to invest that time in training the mind to focus – one step at a time, for example (this is rather rethoric)? We to forget multitasking, rather than “set to forget”?

@unman

If I am using a sharing qube, I can set policies to restrict which
qubes have access to it, whether they have read or write access, AND
(using arguments in policies) what directories they can access.

Regarding sharing qube: I’d never put files there that I’d care enough for. Music, movies, wallpapers, etc - yes. Emails, personal photos, etc - nope! So when it gets compromized - I don’t care about the data in it. That was about the data aspect. Now, since the sharing qube is compromized, what’s the use of your policies in terms of security of other qubes?

@unman

This is in addition to any controls set on the sharing qube.

Since shared qube isn’t meant to acces other qubes, which control exactly will “save” those qubes from compromizing by already compromized shared qube?

Isn’t the only thing that is the real threat is to take the data from compromized qube and process it in other not compromized qube - which is actually the ultimate reason for me not to have shared qube/folder.

Btw,

@unman

AND (using arguments in policies) what directories they can access.

all the data is by default copied to QubesIncoming folder (of a shared qube). Since I wouldn’t copy data to there I would care for, why would I set policies for each folder in QubesIncoming (or elsewhere)? On the other hand, when the data/source qube was compromized prior to copy it to uncompromized shared qube, why would I need the policies?

As I see this: when the qube, I’m copy data from to a shared qube, is already compromized, when it escapes the default QubesIncoming folder, wouldn’t it will be able to escape any other folder set by your policy? Or are we counting that it will compromize only the data in a folder set by your policy and will not escape that folder?

So, even with that, my ultimate, unwritten policy is - if I use shared qube, I don’t care about the data in it, I access it, copy/paste to/from it and proces data from it only with TBDVMs. I don’t care if any data/tbdvm/shared qube is compromized.
Would I need any additional policies for my vision/concept of a shared qube and why? Lateral or escaping towards Xen in this workflow are out of scope of shared qube discussing anyway - it’s a general issue.

@unman

Just because you wear a seat belt doesn’t mean that you cut out the
impact beams.
Depending on the threat you are guarding against you may well armor plate
the car - that doesn’t mean you don’t also wear a seat belt.

On armoring in my previous post, I meant setting your policies, and not wearing the seat belt was meant for being lazy to fire up dedicated qubes for the purposes shared folder/qubes were proposed for, meaning prioritizing and forcing convenience. I might here add that I consider built-ins as the default air-bag add-ons.

I already tried here to emphesize Information Security as a broader perspective. I was lucky enough to become familiar with this field’s standards, and from that point of view its part - IT Security, is almost insignificant not to say irrelevant segment. Not to me, it’s by the standard, and many notorious xkbds are just desribing this in a funny way. Unfortunately, instead of being taken with responsible consideration by ITS people it is mostly taken as disrispectfull and ignorant. And people wouldn’t believe what info could be get only by offering a coffe or a beer to someone (doesn’t matter if accepted).

@unman

Use every available means to reduce risk - in Qubes, that includes
use of policies.

That say, the most is on us and the quality of our risk assesment, not on the (power of the) controls which are at our disposal.

So I’d be delighted one day to find an announcment here that Qubes Team got a new member in a newly opened postion - IS Specialist. I haven’t found any team so far to have such a specialist.

[unman]

I’m afraid that I cant give your questions the time they deserve.
I do think you are reading too much in to those examples.

The first - “the vault” - was intended to show how policies can be used
in the normal case. Nothing more. This is normal Qubes vault.
But you have interesting questions:

So, where the data came from? Generated in vault or/and came somewhere from outside? Which way the latter?

I have a number of vaults - most have data generated internally, or
transferred from non Qubes systems, using qvm-block. For these I have
policies that prohibit write access from other qubes, and limit qubes to
which data can be transferred.

Then, how to generate and store invaluable received emails, photos, videos etc in vault, for example?

I store these in lower grade vaults, if you will, or in shared
folders.
Where it is a standard type vault, the storage is in an offline
ultra minimal qube. As I have said, I don’t care if I am storing
malware infected files. All files are opened in offline disposables.
If I need to use a file or share it, then I use qvm-convert to produce
relatively clean copies.
emails I keep in an offline minimal qube.

Unless I do something irresponsible like this (again convenience, ehm?), by doing that (which I of course wouldn’t), why it isn’t enough what we already have built-in? This is the most important answer I would like to get at the moment.

I don’t see anything irresponsible in creating default policies to ease
transfer between specific qubes without a prompt. That can be convenient,
with small increase in risk, in specific scenarios.

Now, I absolutely understand that your policies prevent picking up the wrong qube in the dialog box gui, but aren’t such wrongdoings out of scope of everything and everyone we interract with, not only of Qubes and vault? There couldn't be as many policies as needed to help us with this. Instead of setting the policy wherever we might pick up the wrong thing, wouldn’t be more effective to invest that time in training the mind to focus ??? one step at a time, for example (this is rather rethoric)? We to forget multitasking, rather than “set to forget”?

Here I agree with the sentiment, (better to train the mind to focus),
but disagree with the practice.
These policies are set because people make mistakes: e.g. that momentary
lapse of focus that means you share a document from the wrong profile.
Good use of policies in Qubes can help mitigate against such mistakes.

My other example was about using a “sharing qube” - not a standard
vault. These use qubes-rsync or sshfs.
I think you may have missed this point, as you seem focussed on
qvm-copy/qvm-move.(Both, of course, are still available, but are not
the main means of interaction between these qubes.)

Regarding sharing qube: I’d never put files there that I’d care enough for. Music, movies, wallpapers, etc - yes. Emails, personal photos, etc - nope! So when it gets compromized - I don’t care about the data in it. That was about the data aspect. Now, since the sharing qube is compromized, what’s the use of your policies in terms of security of other qubes?

Here’s the thing - you are putting that data somewhere - perhaps in a
single qube, or perhaps in a vault of some sort.
Everything you say here applies to that case.

Using a shared folder, or better, a sharing qube, allows you to separate
data storage from other qube functions, and to compartmentalise a single
security domain. All the qubes involved should be at the same security level.

all the data is copied to QubesIncoming folder (of a shared qube). Since I wouldn’t copy data to there I would care for, why would I set policies for each folder in QubesIncoming (or elsewhere)? On the other hand, when the data/source qube was compromized prior to copy it to uncompromized shared qube, I would never process it there anyway, so again, why would I need the policies?

This is where you have missed the point - using a shared qube, you can
allow other qubes to access specific directories with various rights.
Not QubesIncoming, but any directories that you create and specify. You
have complete control over that access.

And, at the end: when the qube, I’m copy data from to a shared qube, is already compromized, that is not the “problem” of a shared qube. When it escapes the default QubesIncoming folder, wouldn’t it will be able to escape any other folder set by your policy? Or are we counting that it will compromize only the data in a folder set by your policy and will not escape that folder?

If you have a compromised qube, then data written to a shared folder may
also be compromised. But in order to escape the folder there would have
to be an exploit in FUSE or sshfs - neither unlikely, but lesser risk
than when storing files in a single qube.

These are convenience mechanisms. They allow users to compartmentalise
security domains and share data within a single domain, without
greatly increasing risk. Undoubtedly better than using a single qube for
these purposes.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

[enmus]

Thank you for the response, unman. I am almost sure i got all the answers I needed. Now it’s time to re-read them again and to think them through. i am sure others will find them helpful too.

[imme-emosol]

Regarding shared storage, both sshfs & nfs turned out to be less of a fit for my usage, nor is copying (qvm-copy) or moving (qvm-move) files) a desirable solution (because of storage size limits, aka budget-limit).

My usage being a (mis)use of qubes for restraining software.
I find qubes very easy to:

• restrain resource usage (“normally” w/ something like cgroup, ulimit) &
• prevent software from affecting the operations of other software (“normally” w/ something like chroot/jail).

I was looking into suggestions mentioned in “Shared folders (perhaps over qrexec?)”: Rudd-O’s shared folders (continued in “Design questions for the next steps of the Qubes shared folders service”) and: qvm-mount, qubes-sync, qubes-intervmfs, detaching and attaching an image to a vm. Concluded my text would be less of a fit for github, went to (and reluctantly joined) this forum and found this topic “Best Way To Setup A Global Share Folder?” where “folders” are mentioned specifically. But using folders does not seem to be a requirement though, so a ‘network attached storage’ of a ‘distributed file system’ also seems fitting. And found the topic “Attach USB device to multiple Qubes at once?”, which implies that read-only access is easy to accomplish.

But for now, I have turned to looking into ‘shared-disk file system’, and into how qubes determines certain device-names and/or the paths for the mount-points (for instance by doing a github search for xvdb). Thinking that such shared storage will need to be network-able from the vm/qube-side, considering a long term goal of qubes-air/-in-the-cloud.

In short, for me, it would be nice, if there was an option for a configurable (rw,ro) shared storage among the storage options in the management interfaces (api, vm manager-vm details).

[solene]

I’d use syncthing on each qube that need to access the files, and a local relay to allow file transfer.

Check if this suits your threat model.

It’s possible to harden the syncthing systemd service by limiting the files it has access to and what it can do in general

I do something a bit similar to keep qubes data synchronized between my two qubes os computers.

[renehoj]

@imme-emosol

In short, for me, it would be nice, if there was an option for a configurable (rw,ro) shared storage among the storage options in the management interfaces (api, vm manager-vm details).

Does all the ro systems automatically detect changes to the file system?

I recently tried doing something similar with an SBC emulating a cdrom drive over a USB connection, and I couldn’t get the host to detect any changes without fully remounting the drive. It seemed like the OS cached the file table and didn’t refresh it after the drive was mounted, probably working from the assumption it was the only host capable of changing the file system while the drive was mounted.

[imme-emosol]

As I am not leaving my qubes-host, I hope to come to a solution that will prevent data duplication.

[imme-emosol]

Caching the file table would make sense for a cdrom, right? From what I remember burning cd’s, they had to be re-inserted after burning as well (and .iso would need re-mount).

[renehoj]

Maybe, but img which is a rw format has the same issue.

[imme-emosol]

Apparently the “special” shared filesystem that makes use of the fact that the VMs use the same storage device, is called virtiofs or something like that.

Maybe someday…, there will be something like a qvm-volume --insecure .

For now I have (againg) resorted to NFS(v4) and got it to work with qvm-connect-tcp, after enabling all debug-related output for logging. Turns out that it initially did not work because it was trying to connect back over a “insecure” port.

The page Security and NFS mentioned sshfs tunnelling (so qvm-connect-tcp should also be possible).

And NFS/Troubleshooting - ArchWiki showed debug options:

rpcdebug -m rpc -s all    # sets all debug flags for RPC
rpcdebug -m rpc -c all    # clears all debug flags for RPC

rpcdebug -m nfsd -s all   # sets all debug flags for NFS Server
rpcdebug -m nfsd -c all   # clears all debug flags for NFS Server

!!! WARNING !!!

!!! “untested” scripts ahead && insecure practice !!!

These scripts should recreate a (nearly) working configuration.
The policy in dom0 would need to be checked,
and nfs-utils would need to be installed in the template(s).
And the nfs-server can be configured to only do v4.

NFSv4 seems to work this way,
that all under the fsid=root is “visible”
but descending into “sub-shares” is checked according to the settings.
This only applies when nfs perceives such a “sub-share” as a separate filesystem.

nfs-client:

qvm-connect-tcp ::2049
# Needs policy in dom0/admin-vm, see 
directoryShares="${HOME:-/home/user}/shares"
mkdir "${directoryShares?}"
mount 127.0.0.1:/ "${directoryShares?}"

nfs-server:

#!/usr/bin/env sh
createBindMountsAndConfigurationForExportFileSystem () {
    directoryNFS="${1:-/nfs-shares/}"
    pathNameRootNFS="${2:-base}"
    eval "mkdir -p \"${directoryNFS?}\"{\"${pathNameRootNFS?}\"${3:-,media,repositories}}"
    shares=""
    for pathName in "${directoryNFS?}"*
    do
        {
            test "${pathName##*/}" != "${pathNameRootNFS?}" ||
                continue
            fakeFileSystem="${directoryNFS?}${pathNameRootNFS?}/${pathName##*/}"
            mkdir -p "${fakeFileSystem?}"
            sudo mount --bind "${pathName?}" "${fakeFileSystem?}"
            shares="${shares?}$(
                printf '\n%s *(ro)' "${fakeFileSystem?}"
            )"
        }
    done
    printf '%s' "${directoryNFS?}${pathNameRootNFS?} 127.0.0.1(rw,fsid=root,insecure) *(ro,fsid=root)${shares?}" |
        >/dev/null sudo tee "${4:-/etc/exports.d/share.exports}"
}
createBindMountsAndConfigurationForExportFileSystem
# :[ evil eval , no spaces possible in path ]:

[na3904a4er]

Under RDP session in windows10 qube, qvm-copy and qvm-open-in-vm do not work in both directions in my environment.
I personally qvm-copy files from storage qube to RDP client(remmina) qube, specifying QubesIncoming directory as Share folder in RDP sesson, enabling editing the files in winVM.
After editing the file in winVM, I have to qvm-copy back to storage qube and replace the old file, resolving filename conflict.
This workflow is stressful and I sometimes forget to replace old files.

[dispuser]

This can be accomplished by an external USB that is attached to more than 1 qube.

Qubes should just allow for this to happen without a physical device. And display major warnings about wrecking compartmentalization the first time the feature is enabled.

Someone wrote about how this could be done internally in Qubes with fake “devices” with an Internal space allocated to looking like a USB but I’m not sure if it’s easy to implement.

Any Standalone VM will not work with many dom0 commands (like copying from a Fedora VM to a PopOS Standalone VM) but devices can be attached to any sort of VM.

[janglingquo_575]

Would any of these solutions be compatible with an HVM? I am trying to move files from a whonix-ws VM into a TailsOS HVM.

When attempting to attach an external USB stick to the TailsOS HVM, an error message:

“qrexec not connected”

Would syncthing be the best option here? Can this be done within a LAN?

Or would it be best to use sys-USB as an intermediary to pass files from one VM to another.

[etaz]

I am using a thing wrapper script around How to mount LVM images to mount a different qube via oneliner:

[user@dom0 ~]$ ./mount-qube -m /mnt client-qube shared-folder-qube

, which mounts shared-folder-qube into client-qube with mount point /mnt.

This especially works great to temporarily mount a persistent directory into an otherwise full disposable qube. It is far more performant than SSHFS or NFS, which run over (virtual) network. Only assumption is: shared-folder-qube isn’t used by multiple qubes at the same time.

For example

• video-processing → disposable qube, processes media files
• media-client → disposable qube, plays media files
• media-storage → shared and persistent storage qube for media files

Now we can first mount media-storage in video-processing for processing tasks, unmount it, and then re-mount it in media-client to play files.

Of course all participating qubes need to be in the same trust domain (whatever that is for you), as shared folder qube might be corrupted by clients. There is always a trade-off between security and convenience.
Given underlying qvm-block is a native Qubes built-in I have full trust in it from security perspective.

In fact this has become my most common shared folders scenario. Maybe Qubes OS developers might provide an GUI solution to mount qubes easily?

[Rudd-O]

I am exploring a different backend for Qubes shared folders. There is a server daemon written in Rust, and i have fallen in love with Rust. It’s gonna be safer than diod currently being used.