Managed to make Whonix-Host in VirtualBox coexist with KVM networking file Whonix-External.xml.
nmcli con show
NAME UUID TYPE DEVICE
virbr0 ecc61543-fa15-4a43-9732-fa99065ff801 bridge virbr0
virbr2 7b784b6c-44e4-4589-8fba-9ab6f322e810 bridge virbr2
Wired connection 1 2ed217e7-866f-3760-926a-11dedcca3182 ethernet eth0
nmcli con down Wired\ connection\ 1
Connection ‘Wired connection 1’ successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/1)
virsh -c qemu:///system net-start Whonix-External
Network Whonix-External started
nmcli con up Wired\ connection\ 1
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
I.e. the trick is to let libvirt (whonix-libvirt-install.service) (virsh -c qemu:///system net-start Whonix-External) run before network manager.
Network manager can deal with it but libvirt cannot.
I don’t see any solution for this with systemd drop-ins in this case because:
/lib/systemd/system/network-manager.service has Before=network.target
while /lib/systemd/system/libvirtd.service has After=network.target.
add Whonix-Host EFI booting support ⚓ T978 add Whonix-Host EFI booting support EFI booting support for INSTALLED Whonix-Host still not working (works for ISO). No progress here. We should probably ask for upstream help (Calamares github?)
2. Severity: not a blocker small issue/might be implemented in a future release
Packaging USBKill ⚓ T552 Packaging USBKill
“Its purpose is to trigger protection events that prevents adversaries from siphoning files/installing malware/running a mouse jiggler. It creates a USB whitelist of allowed devices of which anything else plugged into the machine causes it to erase its RAM and immediately shutdown. This can be adjusted to exclude all devices.”
To sum-up, as of today, and pending decision on “need triage” issues, there are only 2 identified blocking issues:
Implementation of Whonix-Host firewall
Fixing EFI booting problem on installed Whonix-Host
Alternatively, to speed things up, we could decide that the inability of installing Whonix-Host on a EFI machine is not a blocker (as the main innovation we offer is the ability to boot an GRUB/EFI ISO with Whonix VMs pre-installed and pre-configured).
Of course, many other issues will probably pop up once we will have more test time…
Coming back from a looooong pause…
But still alive and willing to complete this project.
I just built Whonix-Host from source, from stable branch (220.127.116.11.4).
Good news: what did work still works apparently (didn’t run extensive tests, but on the surface looks good):
Boot ISO in BIOS mode: OK
Boot ISO in EFI mode: OK
Run VM machines in ISO live mode: OK
Install in BIOS mode: OK
Run VM machines in host persistent (post-installation) mode: OK
“Bad” news (but expected): what didn’t work, still doesn’t work:
Whonix-Host (post-installation) fails to boot in EFI, although installation reports no error
Whonix-Host Firewall and Whonix-Host Tor configuration and anon-connection-wizard are still not implemented (as far as I know)
I have no idea how to work out the Firewall and Tor configuration issues. I hoped someone more knowledgeable would take up the challenge
Meanwhile, I will try to solve the EFI issue. I will contact the debian-live team on Gitlab, see if they can help. I will post the link here once it’s posted.
EDIT: I cannot post any issue there, only pull requests.
I installed grub-efi-amd64-bin (wouldn’t allow me to install grub-efi-amd64) and all its dependencies (7 additional packages, forgot to write down which ones exactly…) in the Host raw file and reburnt the ISO.
Still stuck at “Minimal BASH-like editing…” / “grub>” prompt after installation.
It’s something really small and stupid that is messing (missing?) somewhere. We will eventually find out.
Installation works, and the Host EFI installed machine actually boots into GRUB if repaired using grub> commands or if it is booted with the ISO still in (I know, strange. Same behavior last time I checked in May).
Of course, all these tests are performed in QEMU/KVM (virt-manager) for now, but if it doesn’t work here at this level it won’t work on real hardware.
Yes, exactly. I wasn’t very actively working on it for months, and decided to give it a try with a fresh head. Then I tried to change the name of this directory and bingo!
I am currently testing (and writing this post) using Whonix-Workstation on Whonix-Host installed on real hardware (high capacity USB stick)! Works fine.
Only thing, had to change back the domain name from qemu to kvm, as it was set to qemu for testing purposes in KVM (for nested virtualization). Just a reminder that we need to it back in the release candidate. Otherwise the VMs are unbearably slow.
EDIT: I see that per use qemu if kvm is unavailable for easier Whonix development using ne… · Kicksecure/libvirt-dist@b77262f · GitHub there should be a check during the first installed Host boot for kvm capabilities (If I understand correctly). As I used KVM with virt-manager to install Whonix-Host on the USB stick (easier to debug), that might explain why the VMs xml files were set to qemu on first boot (also in KVM). I should try to run the entire installation process on real hardware to see if kvm domain is correctly set. Then we wouldn’t need to change anything.
If you have suggestions on how to improve that please let me know. Would be good to support this use case somehow. Why not. Installation of Whonix-Host in a VM on USB can be a good idea how beginners/testers since that guarantees really installation to USB. Internal boot disk which the user currently booted from remains unchanged. We also need to keep things comfortable for developers/testers.
( There is also a use case of sometimes running an operating system from hardware and sometimes inside a VM. Suppose you just made a full dd backup and now want to try if the backup is functional. Assign the USB drive to a VM and boot it.)
What would be a sane way to implement this? At every boot iterate over all installed libvirt XLM’s (multiple gateway’s, workstation’s) and change back/forth from qemu to kvm? That seems surprising / intrusive? Users who set up some non-Whonix VM to qemu to notice that these where just changed to kvm after reboot.
A bit hard to script. kvm to qemu includes “remove <pvspinlock state='on'/> from XML file” but qemu to kvm would mean “re-add <pvspinlock state='on'/>”. Re-adding is more difficult because it needs to be added in the correct position.
XML files don’t support comments so comment in/out isn’t possible either.
does the host firewall need to be an issue here? currently, on numerous other implementations of whonix, no such firewall configs are used. would a solution be to have the typical “all incoming ports” disabled with the standard disclaimer that the host itself should not be used for standard workstation activities?
as a side note, i don’t think restricting network traffic to the gateway will work. it would prevent system updates on the host os. so, there is going to need to be an allowance for some host network activity.
i’m very glad to hear that progress is still being made here. but, if it’s near done, i’m not sure the lack of a perfect custom firewall should block release.