Allow starting only selected AppVMs as DispVM

[marmarek]

Follow up from #866 - allow only selected AppVMs to be started as DispVM. It should be a VM property like dispvm.
The property should affect following things:

• allow starting a VM as DispVM
• change private volume type from read-write to origin

It shouldn't be possible to change the property when VM is running or there exists any DispVM based on it.
Related task: after implementing this property, add support for old dispvm_netvm setting to migration tool.

[jpouellet]

What is the intended benefit of this?

[jpouellet]

What is the intended benefit of this?

[marmarek]

Avoid mistakes like opening untrusted (or in fact: any) document in DispVM based on some private-data-holding VM (like vault).

[marmarek]

Avoid mistakes like opening untrusted (or in fact: any) document in DispVM based on some private-data-holding VM (like vault).

[andrewdavidwong]

Avoid mistakes like opening untrusted (or in fact: any) document in DispVM based on some private-data-holding VM (like vault).

Accidentally opening a sensitive file in a DispVM is only a problem if the DispVM does not inherit the parent VM's NetVM, firewall rules, and RPC policies. Correct?

[andrewdavidwong]

Avoid mistakes like opening untrusted (or in fact: any) document in DispVM based on some private-data-holding VM (like vault).

Accidentally opening a sensitive file in a DispVM is only a problem if the DispVM does not inherit the parent VM's NetVM, firewall rules, and RPC policies. Correct?

[marmarek]

This is about the opposite situation - sensitive is not document opened, but data in private.img of DispVM. DispVM do inherit private.img of it's "DVM template" (read-only, like AppVM have root.img of its template). The thing is, in Qubes 4.0 it will be possible to use any VM as "DVM template" (not only one as in Qubes 3.x), so we should have some safeguard against mistakes I've described. In addition to appropriate qrexec policy.

[marmarek]

This is about the opposite situation - sensitive is not document opened, but data in private.img of DispVM. DispVM do inherit private.img of it's "DVM template" (read-only, like AppVM have root.img of its template). The thing is, in Qubes 4.0 it will be possible to use any VM as "DVM template" (not only one as in Qubes 3.x), so we should have some safeguard against mistakes I've described. In addition to appropriate qrexec policy.

[andrewdavidwong]

Oh, I see. So, the risk is that I open a DispVM based on vault, then I open a malicious document from untrusted in that same DispVM. The malicious document then compromises that DispVM and leaks sensitive data (read-only from vault). Is that right?

[andrewdavidwong]

Oh, I see. So, the risk is that I open a DispVM based on vault, then I open a malicious document from untrusted in that same DispVM. The malicious document then compromises that DispVM and leaks sensitive data (read-only from vault). Is that right?

[marmarek]

On Wed, Mar 01, 2017 at 01:55:22AM -0800, Andrew David Wong wrote: Oh, I see. So, the risk is that I open a DispVM based on `vault`, then I open a malicious document from `untrusted` in that same DispVM. The malicious document then compromises that DispVM and leaks sensitive data (read-only from `vault`). Is that right?

Yes, exactly.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

On Wed, Mar 01, 2017 at 01:55:22AM -0800, Andrew David Wong wrote: Oh, I see. So, the risk is that I open a DispVM based on `vault`, then I open a malicious document from `untrusted` in that same DispVM. The malicious document then compromises that DispVM and leaks sensitive data (read-only from `vault`). Is that right?

Yes, exactly.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?