Qubes inter VM FS

[M. Dietrich]

Hi all,

i created a poc of a file-sharing-between-VMs-concept. it
utilizes fuse and qubes-rpc to make a whole directory from one
VM visible in another VM.

get the code from https://github.com/emdete/QubesInterVMFS if
you like to give it a try.

i urgently needed such a thing so i gave it a try. it's just a
poc but works as expected. the code is small and clear so a
security review should be easy.

M. Dietrich

[M. Dietrich]

[M. Dietrich]

i changed the name of the project so it is now found under https://emdete.github.io/Qubes-InterVMFS/

[Vít Šesták]

Hello,
I was just curious, so I have looked at the code:

1. I generally don't like patterns like this:

a = transform(a)

You reuse one variable name for multiple purposes and this makes reading the code harder.

2. You use JSON as data exchange format. JSON parsing can be viewed as needlessly complex. One might argue the risks are not so high in most scenarios, but I don't feel it to be “the Qubes way” there.

3. You identify files by inode numbers. When I guess inode number, what prevents me from escaping from my root directory?

4. How is directory traversal prevented?

Note that I've taken rather a brief look, it was not a deep review.

Regards,
Vít Šesták 'v6ak'

[Jean-Philippe Ouellet]

On Mon, Mar 13, 2017 at 3:02 AM, Vít Šesták
<groups-no-private-mail--con...@v6ak.com>
wrote:

> 2. You use JSON as data exchange format. JSON parsing can be viewed as needlessly complex. One might argue the risks are not so high in most scenarios, but I don't feel it to be “the Qubes way” there.

Anecdotally, I can confirm that I do remember seeing several places
where we explicitly avoid parsing JSON in the qubes code base where
simpler serialization will suffice. I came across another just a few
hours ago [1].

[1]: https://github.com/QubesOS/qubes-builder-github/blob/master/notify-issues#L81-L92

[Jean-Philippe Ouellet]

Archive-friendly link:
https://github.com/QubesOS/qubes-builder-github/blob/551852b2bd49f9506f01a76e463fa91e39c1fd77/notify-issues#L81-L92

[M. Dietrich]

Am Montag, 13. März 2017 08:02:58 UTC+1 schrieb Vít Šesták:

1. I generally don't like patterns like this:

a = transform(a)

You reuse one variable name for multiple purposes and this makes reading the code harder.

point is i don't leave the object around. i like that pattern. anyway, this is a POC, no more, no less. once someone likes it she should reimplement it in C. 

2. You use JSON as data exchange format. JSON parsing can be viewed as needlessly complex. One might argue the risks are not so high in most scenarios, but I don't feel it to be “the Qubes way” there.

again: a POC, for faster implementation i choose JSON. 

3. You identify files by inode numbers. When I guess inode number, what prevents me from escaping from my root directory?

yes, that is  a know thing and as far as i remember i even mention that myself. 

4. How is directory traversal prevented?

you can't escape as far as i know. if you find out how it's a bug which must be fixed. 

Note that I've taken rather a brief look, it was not a deep review.

sure. thank you for that. 

i threw that in as a usability enhancement. just to play around with such a feature. many other solutions come to mind when it comes to inter vm file exchange. this was just one that i implemented to see how that "feels" and if transport via that queue is fast enough.

my presonal outcome is: i like it and it's fast enough. next steps would be reimplemantation, security review, gui integration. 

[lok...@gmail.com]

On Tuesday, 14 February 2017 14:49:11 UTC+8, M. Dietrich wrote:

 

i created a poc of a file-sharing-between-VMs-concept. it
utilizes fuse and qubes-rpc to make a whole directory from one
VM visible in another VM.

In terms of security policy, would this be considered safer than the alternative: To open NFS between the VM's. The advantage of this is that dom0 isn't involved at all, meaning that in a worst case scenario, only the involved VM's would be compromised.

[Vít Šesták]

I don't see any extra exposure for dom0 there. Yes, there is some qrexec call managed by dom0 (but handles by another AppVM) and this adds some (very very marginal, thanks to qrexec simplicity) risk compared to not allowing any qrexec call. However, there already are some other qrexec calls that bring the same or higher risk. See commands like qvm-open-in-dvm or qvm-run '$dispvm'. In background, they are at least the same case in terms of risks.

NFS also brings some complexities. They aren't related to dom0, but rather to AppVMs, firewall config etc.