Best Way To Setup A Global Share Folder?

[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.