search

ElliotKillick / qvm-create-windows-qube

Spin up new Windows qubes quickly, effortlessly and securely on Qubes OS
https://elliotonsecurity.com
MIT License
347 stars 45 forks source link

Make running in dom0 optional #19

Open iamahuman opened 4 years ago

iamahuman commented 4 years ago

Qubes R4.0 introduced Qubes Admin API, which allows a VM to manage other VMs on a Qubes system without assuming full privileges of Dom0.

All the qvm-* commands work the same, so perhaps the only thing really needed might be replacing qubes-dom0-update with directly downloading the QWT ISO.

ElliotKillick commented 3 years ago

Yes, having one ultimately trusted Dom0 script was a design decision I made when I first created the project. Mostly because it was easier (as I didn't have an abundance of time) and the Qubes Admin API was something I was less familiar with (less chance of creating bugs).

But also for security reasons, allow me to explain. The purpose of the windows-mgmt VM is to act as a "blast door" if for example the ISO filesystem is malicious and tries to exploit a bug in the Linux filesystem parsing. However, when using Qubes Admin API, the configuration of the Windows VM is also done in windows-mgmt. I see this could go wrong if for example the then exploited windows-mgmt configured the Windows VM to use a different NetVM then what the user wanted thus potentially allowing the malicious windows-mgmt to access unintended networks behind different NetVMs. There are also other potential examples but this is the first that comes to mind.

@fepitre has already implemented the use of Qubes Admin API only for the upcoming R4.1 (although there is no Qubes Windows Tools compatible with R4.1 yet, this is just in preparation): https://github.com/fepitre/qvm-create-windows-qube https://github.com/fepitre/qubes-mgmt-salt-windows-mgmt

Thoughts on this security concern @fepitre or is this just a bit too paranoid (lol)?

iamahuman commented 3 years ago

Yes, having one ultimately trusted Dom0 script was a design decision I made when I first created the project. Mostly because it was easier (as I didn't have an abundance of time) and the Qubes Admin API was something I was less familiar with (less chance of creating bugs).

Understandable. Thanks!

But also for security reasons, allow me to explain. The purpose of the windows-mgmt VM is to act as a "blast door" if for example the ISO filesystem is malicious and tries to exploit a bug in the Linux filesystem parsing. However, when using Qubes Admin API, the configuration of the Windows VM is also done in windows-mgmt.

I was talking about a paranoid configuration with two VMs, one that talks to dom0 and other that manages the Windows VM.

This is similar to how qvm-backup-restore itself can run in an AppVM, which may in turn read the backup file from another AppVM.

I see this could go wrong if for example the then exploited windows-mgmt configured the Windows VM to use a different NetVM then what the user wanted thus potentially allowing the malicious windows-mgmt to access unintended networks behind different NetVMs. There are also other potential examples but this is the first that comes to mind.

@fepitre has already implemented the use of Qubes Admin API only for the upcoming R4.1 (although there is no Qubes Windows Tools compatible with R4.1 yet, this is just in preparation): https://github.com/fepitre/qvm-create-windows-qube https://github.com/fepitre/qubes-mgmt-salt-windows-mgmt

Thoughts on this security concern @fepitre or is this just a bit too paranoid (lol)?

Perhaps, but this is an optional feature anyway.

ElliotKillick commented 3 years ago

Hm, yeah. My only concern is the amount of memory that would take up also considering the Windows VMs themselves which as currently configured in the script require 1GiB of memory to start up.

I see in my Qubes Manager I have a default-mgmt-dvm qube. I suppose we could use this to configure the Windows VM itself in a paranoid configuration.

ElliotKillick commented 3 years ago

Note that it's also in the road plan to use libguestfs for more secure interaction with the ISO meaning we won't have to mount it at all. Check the todo list item I recently added in the README for more details.

IOZZYS commented 9 months ago

Interesting tool... I'm interested in that paranoid set-up^ Working on a tool for Qubes myself (noticed some overlap with qubes-task, will look into that aswell), but later down the line I would love to add that paranoid setup as an option if you haven't worked on it yourself yet, and then integrate this into my tool (or expand heavily on qubes-task which already integrates your tool).