Best Way To Setup A Global Share Folder?

General Discussion
41

1. “When it fails…”
2. “… the effectiveness of the risk treatment plan is now regarded as being more important than the controls.” Sounds familiar?

It’s not if, but when. And ITS is just a tiny fragment of a huge puzzle.

So, as I see it, the way you write about it, your first “usecase” belongs to “I know what I’m doing” (“I could…, or I could…”), and the other one to “It won’t happen to me” ("… but he has to do that all in the short time…").

P.S. for those lazy to read, unman never wrote about sharing in the linked note, but about qvm-move/copy and qubes-sync.

42

not sure that I know what I’m doing tbh :-s

Would following uman’s guide for qubes-sync make our system vulnerable?

43

oh my, just an empty file lol

Alright! it works! thanks :smiley:

although, reading @enmus … is it safe to do so?

44

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

3 Likes
45

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

46

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?

47

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.

48

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.

50

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.
2 Likes
51

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

1 Like
52

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
53

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

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.
2 Likes
54

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…

55

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

56

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?

3 Likes
57

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

58

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
59

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.

60

too strictly say, it just not recommended

61

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.