user@host:~$ virsh -c qemu:///system net-start "default"
error: Failed to start network default
error: internal error: Network is already in use by interface eth0
The VBOX NAT default interface connecting the Whonix-Host VM to your host uses the same IP range maybe?
Anyway not a blocker I think since Whonix-Host is not really designed to run in a VM.
No. Upgrades installed in Whonix-Host ISO mode are not applied when later installing using calamares installer. These are missing in Whonix-Host installed. No idea why. Maybe calamares copies ISO contents and ignores the overlay. That might be a feature, not a bug.
We’d have to configure KVM to have an external network in a different range however that will break networking since we ship one set of network confs for all non-Qubes versions. I had to figure out a way to make KVM use the same network settings as VBox when we switched off dhcp.
We’d have to configure KVM to have an external network in a different range however that will break networking since we ship one set of network confs for all non-Qubes versions. I had to figure out a way to make KVM use the same network settings as VBox when we switched off dhcp.
Nope has nothing to do with baremetal’s IP management and everything to do with NAT network config for hypervisors. So it has to stay this way to avoid creating different settings for KVM vs Vbox.
Whonix-Host (currently running inside VirtualBox) is now networking is now by network manager. eth0 got automatically assigned 10.0.2.15.
Now Whonix-Host networking (currently running inside VirtualBox) is functional and both gateway and workstation are starting.
Speed in nested virtualization is too slow to test if networking inside VMs is functional but I will assign more RAM and try again. Can also say more when I build a new image that doesn’t require all the manual changes I did during experimentation.
However, maybe likely this will work?
For QEMU support both of these shouldbe removed?
gateway (actually works without removing this):
<vcpu placement='static' cpuset='0'>1</vcpu>
workstation:
<vcpu placement='static' cpuset='1'>1</vcpu>
Removal was required for me inside VirtualBox. Otherwise I was getting cannot set CPU affinity on process error when trying to start workstation.
Whonix tag 15.0.1.3.2-developers-only should build.
Though, only tested with --remote-derivative-packages true. And had a minor hiccup which hopefully was just a one time thing.
dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt
dpkg-deb: error: <decompress> subprocess returned error exit status 2
dpkg: error processing archive /var/cache/apt/archives/calamares_3.2.4-3_amd64.deb (--unpack):
cannot copy extracted data for './usr/lib/x86_64-linux-gnu/calamares/modules/keyboard/libcalamares_viewmodule_keyboard.so' to '/usr/lib/x86_64-linux-gnu/calamares/modules/keyboard/libcalamares_viewmodule_keyboard.so.dpkg-new': unexpected end of file or stream
Errors were encountered while processing:
/var/cache/apt/archives/calamares_3.2.4-3_amd64.deb
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.
A lot of progress has been done lately on the Whonix-Host project.
I think we are quite close to be release-ready, at least in beta state. I also thought a nice sum-up of what blockers/issues remain would be nice to set priorities
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?)
co-install grub-efi-amd64 and grub-pc by default on Whonix-Host ISO ⚓ T979 co-install grub-efi-amd64 and grub-pc by default on Whonix-Host ISO Note: this is a blocker only if the possibility of installing Whonix-Host without Internet access is a requirement. Otherwise the correct grub version is downloaded by Calamares during installation
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…
Greetings!
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 (15.0.1.3.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.
In the meantime, if we want the EFI installation to work, we must add the modules sources-media
and sources-media-unmount
in /etc/calamares/settings.conf otherwise it will fail to download the package grub-efi-amd64 during the installation process and the installation will abort.
See pull request: Update settings.conf.dist by onions-knight · Pull Request #4 · Kicksecure/live-config-dist · GitHub
Merged. Now included in 15.0.1.5.2-developers-only.
A bit non-ideal to download during installation but we can perfect that later (somehow cache the package during build process).
EFI booting might be broken because of this. In a VM with grub-pc installed:
sudo apt install grub-efi-amd64
The following NEW packages will be installed:
efibootmgr grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed mokutil shim-helpers-amd64-signed shim-signed shim-signed-common
shim-unsigned
The following NEW packages will be installed:
grub-efi-amd64 grub-efi-amd64-bin
These Recommends: in Debian packaging terms might actually be required for successful EFI booting.
Since Whonix source code doesn’t mention grub-efi or other packages in the build script or in anon-meta-packages, I guess that could be why EFI booting is broken.
Great suggestion.
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.