Hello David,

Thank you for the open feedback.

> I think you have some misconceptions here
> - the main one being why people tend to use
> Qubes OS: Segregation of data to application-
> specific domains, i.e. impact of a domain
> compromise is limited.

You are right, regarding why people use Qubes.
But depending on specific workflows there is a need to either work with cloud 
storage for collaboration or to switch the OS completely for this use case.
Think about a (cloud based or on premise) storage service which is used by 
several people.
My goal is to work 100% in Qubes and I think that splitting access of data and 
local storage offers a better security than having the data synced and stored 
in one AppVM.
And I tried to build something that makes it easier to access data from various 
VMs in an easy way (knowing that it is less secure than using qvm-copy-to-vm).
But using some scripts we can reduce the attack surface on nfs in such a way, 
that we only enable NFS/open ports when access is needed.
I can't see how this approach is less secure than using one VM for 
syncing/storing/accessing the data?

> Your idea however makes your Qubes
> installation vulnerable to: - Any attacks
> originating from that OS ("files should still be
> accessible/decryption from other Operating
> systems")

True, but wouldn't this mean that the AppVM which is working as NFS Client must 
be compromised before NFS is attacked?

> Nfs-based attacks (basically all your AppVMs
> using nfs will be vulnerable to all nfs
> vulnerabilities

NFS access to the server is allowed on a per VM basis (firewall allow per IP), 
shouldn't this be enough to reduce NFS attack surface?

> encfs based attacks which people can even
> find on wikipedia.

Yes true, it is a shame, that we still don't have a multiplatform open source 
encryption standard that could maybe also be adapted by cloud storage providers.
But as mentioned the idea could also be implemented with other encryption 
solutions like CryFS, ...

> if you don't want to add
> another idea to the security circus
> I'd reconsider either using Qubes OS, your
> other OS or your architecture.

Hmm ..., why should I abandon Qubes and use a much more less secure OS just 
because working with cloud/external storage is part of some (!) of my workflows?

Even if all VMs which I use in the described solution are compromised, I can 
still have other VMs which are fine.
So basically it's one more reason to use Qubes ;-)

[799]

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/oZiNcfSwB33LIJmkEc-H483lwPzzbGTv-Wbwrq9BnvNnuyLKXbc1yshBcPkBf5MeimHjaCULUTr-XgLh70ZV_tMW4IJ68RG220hccF2Pqso%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to