Hi again,
On 10/15/2017 08:37 PM, '[799]' via qubes-users wrote:
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.
Ok, that's something I can understand. So far I was under the impression
that all of your VMs were using that cloud backed storage.
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?
The point here is that it's not much more secure neither. In fact you
might even introduce unwanted mistakes (mistakenly opening ports to one
of your other VMs e.g.), which ultimately could lead to the compromise
to one of your other VMs.
Attacking a nfs implementation shouldn't be too hard for a dedicated
attacker, i.e. you can bet that a compromise of any of your
nfs-connected VMs would lead to a compromise of _at least_ all of your
nfs connected VMs. Which is equal or worse than what you had without
that idea.
So the standard attack path would be:
other OS --> nfs-client VM --> other nfs VMs
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?
Yes, also holds for the standard Qubes OS model though (you running your
nfs client in the same domain where you have your nfs data).
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?
No. Protocol & implementation vulnerabilities exist.
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, ...
I don't know that one.
Anyway file-based encryption suffers from revealing meta data such as
file access timestamps, number of files, work activity, maybe even
folder structures.
Volume-based encryption doesn't tend to have these issues. The
containers of the truecrypt successor should also be supported by
cryptsetup if I recall correctly.
Assuming the other OS is Qubes OS you could do one encrypted
voloume/container per Qubes domain and do an implementation as follows:
- mount the remote fs in some "distributor" appVM, e.g. using sshfs
- use qvm-block from dom0 to attach the encrypted containers from the
distributor VM to the respective target domains
- decrypt the containers in the respective domains using keys that can
only be found there
That implementation still suffers from parsing attacks on cryptsetup,
but the others should be identical to attacking Qubes OS itself.
It might be possible to mitigate potential cryptsetup issues by writing
an own qrexec service, but that should be left to the pros...
The performance should be roughly as good as reading & writing from a
network backend is in general.
For non-Qubes OS systems I don't see the point of separating domains
though. The other OS doesn't do it neither.
KR
David
--
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/b5758a2c-bcdd-aa2b-ece9-b7031e22d59a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
