Best Way To Setup A Global Share Folder?

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.

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

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.

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”?

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?

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.


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.

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

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.

1 Like

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:

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.

I store these in lower grade vaults, if you will, or in shared
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.

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.

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

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.

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.

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.

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.