Consider supporting Xen's Virtual Machine Introspection / DRAKVUF

[andrewdavidwong]

On 2016-11-04 02:35, Zrubi wrote:

Intrusion/virus detection inside the affected VM not really makes sense.

However newer Xen versions has a nice feature:
https://wiki.xenproject.org/wiki/Virtual_Machine_Introspection

And already a real project using this feature:
https://drakvuf.com/

That feature wound really make sense and would fit in Qubes philosophy
pretty nicely.

[rootkovska]

There are lots of problems that VM introspection presents to security of a system like Qubes OS. Architecture-wise.

The biggest one is that even if we allow read-only access to memory and contexts of the VMs, we should still assume the Introspection VM would be able to establish a communication (covert) channel with any of the VMs in the system, including the least trusted on. This means the read-only Introspection VM is hard (or even impossible) to realize currently, especially on Xen. Now, because we need to assume that the (complex) logic inside such an Introspection VM will be exploitable, this means we're negating VM isolation in the system.

It's worth thinking if the above problem could be satisfactory solved by introducing many Introspection VMs and enforcing that each of them has access to only one AppVM?

[rootkovska]

There are lots of problems that VM introspection presents to security of a system like Qubes OS. Architecture-wise.

The biggest one is that even if we allow read-only access to memory and contexts of the VMs, we should still assume the Introspection VM would be able to establish a communication (covert) channel with any of the VMs in the system, including the least trusted on. This means the read-only Introspection VM is hard (or even impossible) to realize currently, especially on Xen. Now, because we need to assume that the (complex) logic inside such an Introspection VM will be exploitable, this means we're negating VM isolation in the system.

It's worth thinking if the above problem could be satisfactory solved by introducing many Introspection VMs and enforcing that each of them has access to only one AppVM?

[tklengyel]

Indeed, granting an introspection VM blank VMI access to all domains would by definition negate hard isolation between them. Also, as you say, with XSM it is very much possible to restrict the introspection access to specific domain(s) and also to run the VMI logic from dedicated VM(s). I already require users of DRAKVUF to deploy Xen with a custom XSM policy like that (see tklengyel/xen@bfdf206).

[tklengyel]

Indeed, granting an introspection VM blank VMI access to all domains would by definition negate hard isolation between them. Also, as you say, with XSM it is very much possible to restrict the introspection access to specific domain(s) and also to run the VMI logic from dedicated VM(s). I already require users of DRAKVUF to deploy Xen with a custom XSM policy like that (see tklengyel/xen@bfdf206).