Best Way To Setup A Global Share Folder?

@apoawaisoChae following any guide without understanding what it is you are doing will potentially make your system more vulnerable. This entirely independent of the guide or its author.

In general setting up a global share folder is a horrible idea for security.

If someone knows what they are doing, what the real world impact of their actions are, and they accept the resulting risk as appropriate for a specific circumstance, then they might go that route for the sake of convenience.


You must consider the security implications in sharing data between qubes.

Yeah about that… when editing /etc/qubes/policy.d/30-user.policy

after doing [user@dom0 ~]$ qvm-tags client add sshfstest this works:

qubes.ssh * @tag:sshfstest @anyvm allow target=server

but this does not:

qubes.ssh * client @anyvm ask target=server

What is the syntax to give only one specific qube access? Or is giving it a unique tag the only way?

@ enmus, is this the right approach? giving one specific qube access to one specific other qube? Or will this introduce vulnerabilities?

[edit] to clarify: I don’t mind that when an attacker compromises client, he also has access to the data on server but I do not want that same attacker to have access to @anyVM’s data. Does the policy above prevent that?

While I have to agree that read/write access to a shared folder essentially defeats the purpose of security by compartmentalization, granular read-only access to data from a networked (or privileged) qube to a non-networked qube has numerous applications, especially when it comes to optimizing performance across the entire system.

The issue with the current system of viewing potentially dangerous files involves copying these file over to a restricted dispVM, which is slow and resource expensive. Preloading the dispVM and employing a mechanism to auto copy files over to it may improve the situation, though it still prevents itself as clunky and resource intensive.

I believe that the best way to address this problem is to implement a protocol that is unidirectional (or near unidirectional) that can facilitate read-only streams. That way, a single qube can be dedicated to viewing all digital content that doesn’t need to be modified. This has a number of benefits:

  1. Far less overhead
  2. Videos and offline video games that require graphics acceleration can take advantage of GPU passthrough safely
  3. Data can be safely cached if frequently accessed

Of course, at first glance, this comes with the blaring conundrum of putting all your eggs in one basket; if the central vm was to escalate out of and into a vm with network access, the implications could be devastating. However, as long as we make these two reasonable assumptions…

  1. Xen is secure in that it prevents malicious escalation into dom0
  2. Xen’s qrexec framework in particular is secure in that it prevents bi-directional communication between qubes

…then viewing ten files in one central vm would be no different (security wise) than firing up ten dispVMs and viewing them in each one, aside from the massive decline in performance.

both to @in7ziVfV @queue

… and again, yet another “If…”

When we forget “If” word and start to ask ourselves “when it happens, what then”, we will not clear the fog, but will find new ways to get to the point. And that is what I find Qubes OS is all about, and that is exactly why I use it, but not the other ones.

To the core: I have no doubt, the day basic programming loop/algorithm begin to start with “When->Then” instead of “If->Then”, there will be way, way less bugs in the software.

Try to create one simple basic this way and you’ll hopefully discover how much steps ahead you are comparing to the one thinking through “If->Then” loop.

Call to me, and I will answer.

I would not set up a globally shared folder - but I can see that some
people might want to do so. There is no reason why such a resource
necessarily weakens security.
Qubes is incredibly flexible and you can use and abuse it as you will,
depending on your security model and your needs.

Some users will compartmentalise their digital life - others wont. But
they will still benefit from the separation provided by service qubes,
and the ability to use disposables.

If you are using Qubes to serve a single security domain, it may
make sense for you to have a globally shared resource. You can still
control access to different parts of it with different capabilities
(read only, read/write, write only) using the qrexec policy framework.
If that is OP’s position, then there are various possibilities, as shown
in this thread.

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

A clear, clarifying and non condescending answer which allows freedom of choice and suddenly all frustrations are gone!
Thank you @unman

1 Like

if the same file is being used by different qubes, maybe it makes more sense to just have all that related workflow inside the same qube?

Would cloud sync software on each VM be more secure than a locally shared folder?
The VM would still technically be network gapped from any kinda lateral movement exploit, but could be used to sync a malicious file between all qubes

1 Like

Perhaps it would.
Most likely not.

Take a simple example - I use Qubes for work: searching the net for
information, writing reports, and email.
I could do this in a single qube.

Where is the risk? A malicious web site could be an attack vector - if
successful the attacker could have access to email, and to my reports.
Perhaps I decide to improve things by using disposables for the net searching.

I have not removed the risk, but I have reduced it. Now a malicious site
would have to set an attack that included inter-qube processes.

Where is the risk? A malicious email could be an attack vector - if
successful the attacker could have access to my reports and all email.
I decide to use a separate qube for my email - perhaps I use split mail,
and open attachments in offline disposables.

Now I have a qube for email (perhaps more if I use split mail); a qube
where I write reports, disposables for net searching, and I open
email attachments in offline disposables.
It makes some sense to have a separate repository shared between
these different qubes - I could copy information from the net, and
from email, directly in to the report qube, or I could separate storage
from use. I can use qrexec policies to control what access these qubes
have to the shared archive.

Separating out activities in to these different qubes has helped reduce

Where is the risk? Malicious content? Content is not accessed except in
disposables. At this stage I don’t care if I have malicious files
stored in the shared archive, because I do not open it there, but I
can still access the content.
I decide to separate image processing from data processing, using
distinct disposables, based on minimal templates.
If I intend to share the files, then I use native Qubes tools
(qvm-convert-img and qvm-convert-pdf) to sanitise them. I may also
use a scanner qube.

Now I have quite a few qubes: I use qrexec policies to control the
flow of information, and mimeapps to make sure that files open in the
right disposables.
Many qubes interact with the same file from the shared archive.
Still risk, but reduced: and we can go further, as we identify risk and
try to mitigate it.
Qubes tools and policies let you build this as you will.

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

Yeah… but what I actuall mean is…:

  1. I can read
  2. I understand English
  3. I get that qubes-ssh-forwarder@.service calls /usr/bin/qrexec-client-vm
  4. I have read qrexec-client-vm and Qrexec: secure communication across domains
    But I have no clue what every little piece of software that is involved does!

And apparently neither do those who developed Qubes-OS, as until 4 years ago they had no clue about Qrexec policy bypass and possible information leak

So the conundrum is… We’re not supposed to play with it until we know what we’re doing (aka get experienced)
But to get experience we have to play with it…
And even if we do gain experience and start to think we have a vague idea of what’s going on… then the experts show us that even they are not omniscient either! So who am I as common user to ever be able to claim I know anything?

Reading this thread I notice a lot of frustration in both the experts camp and the newbie camp. To me that shows that documentation is lacking. Maybe someone experienced can document the correct way for us newbies, and if there is absolutely no way to share storage with some specific VM’s in a safe and secure way… then maybe explain why exactly (sshfs is not safe because of … and rsync is not secure because of … etc, and how is qvm-copy/move different as that does seem safe (or is it not?)). But unman seems to think it’s possible and safe when careful.
Maybe this documentation already exist, and I (and others) somehow missed it from Documentation | Qubes OS ?
I’m happy to help write and/or review such a document, giving feedback from a newbie’s point of view.

And just as I write this I see @unman’s response. I am convinced that unman’s post copied (even as is) to Documentation | Qubes OS would be a huge help! It also triggers more food for thought on possibilities I hadn’t thought about (mimeapps).
@unman the biggest risk for us newbie’s is user error: messing up the RCP-policies…

Please correct me if I’m wrong here: sharing folder (needs work) → setting policies to it for each qube accessing it (additional work).
If yes, isn’t this overhead comparing to simply create tbvm “shared qube” automatically started on boot keeping it constantly opened and using native Qubes tools to manipulate files to/from it? Of course, in a safe way as you further
elaborated, since that isn’t a part of sharing folder elaboration.

Please help me to even better comprehend Qubes concept

I still haven’t seen any compelling example that demonstrates the need for a shared folder between qubes or domains even. I remain open to be educated.

My current view is that I essentially have 5 types of qubes:

  • offline, store (holds valuable data, no edit/view software installed beyond file manager)

  • offline, store with specialized view/edit software (e.g. calibre, keepassx, music player)

  • offline, disposable, view/edit (this is where the valuable data gets viewed/edited)

  • online, firewalled, with state and specialized software (e.g. IDE, compiler – holds source code or similar files, connection to github or the like only)

  • online, open, with (login) state, no data (specialized for streaming/shopping/medical/banking)

  • online, open, disposable (for all other online activity)

What I am asking is: what is a possible workflow that cannot be done without a shared folder or which would be so burdened by qvm-open-in-(d)vm that it is impractical without a shared folder?


I’m not clear exactly what you mean.
Using native tools, by which I assume you mean, qvm-copy and qvm-move,
you also need to set policies.
The only additional work is in setting up the shared folder in the first

Hey unman. Thanks for your response. The whole idea is obviously too odd for me, that I don’t see why would I’d need policies for. To me it’s like I’d armor my car for the sake of convenience of not putting the seat belt on.

And I’d say that we’re divided here worse than vaxxers and anti-vaxxers were at the moment, haha. Sorry, but I was using VirtualBox for ages, and the day I realized that at any cost I have to put my host offline while VMs were online, was the day Qubes was destined for me to ran at.

1 Like

You don’t need to setup the global sharing folder for all of them due to the security concerns about “why would you do this?” error message, if this has it, or straight breaking the system.

too strictly say, it just not recommended

I’m not quite sure what this means.
You use policies to regulate the data flows between your qubes.
In my opinion, it’s a key part of setting up a Qubes system, and
customising it for each user.

For example - I have a qube, offline and used to store some data. Let’s
call it the vault.
I set policies to deny any other qube from accessing the vault, or
writing to it.
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.

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.
This is in addition to any controls set on the sharing qube.

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.

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

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

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.