Also the umask changes (later undone already) might cause some issues.
I am building either in Debian buster VMs (with newest security-misc package) or in Whonix VMs which are updated from testers repository. That might make the difference if you’re using stable or testers version of Whonix.
The “old” VM is an up-to-date debian buster VM. I always built Whonix with it, without problems, until now, where it always fails.
The newer one is a Whonix-Workstation VM, didn’t check the repos I am using.
OK, so I recreated a fresh debian buster VM as build machine (not a Whonix Workstation).
First remark: there are a bunch of packages that are needed in order to build Whonix that are not listed in the building documentation and that I had to add manually. Maybe worth updating the documentation?
The good news: the build finally succeeded
Well, it did fail at ././build-steps.d/2550_convert-raw-to-iso**
+++ cp /home/user/whonix_binary/image/boot/isolinux/
cp: missing destination file operand after '/home/user/whonix_binary/image/boot/isolinux/'
As far as I understand the real cause is that I had no directory /usr/lib/syslinux on the building host, and therefore the following cp command could not be executed: cp /usr/lib/syslinux/modules/bios/* "$WHONIX_BINARY/image/boot/isolinux/" Installing syslinux package on the building host solved the problem.
ISO seems to work. Boots normally into X. I will do more tests tomorrow.
Ok, I’ll try to update the list later. Nothing urgent.
Used for legacy bios boot. Not sure why isolinux instead of grub2… Grub2 is used for EFI bios. This is why we have both in the ISO file. If you boot the ISO in EFI mode, it automatically loads the grub loader. See screenshots below (KVM virtualization, not real hardware):
New issue with virt-manager (both on ISO and install target): Error connecting to graphical console: Error opening Spice console, SpiceClientGTK missing -> FIXED by adding package gir1.2-spiceclientgtk-3.0 and needed dependencies
2. Calamares Installer
Needs correct branding -> still to be done (see also: Whonix Host Calamares Branding Suggestion) Problem: shouldn’t we need a complete new branding now that Whonix-Host has been officially relabeled “Kicksecure”? Shouldn’t we be installing Kicksecure on the install target instead of generic “Whonix-Host”? Any existing suggestions for graphical design?
Does it work in EFI mode? Still failing in KVM, maybe related to virtualization, will try on real hardware.
3. Whonix-Host install on HDD
at least one of the kernel hardening boot parameters somehow messes with the CPU detection on the host -> needs testing on real hardware, see if it still an issue
the installed system has no virtual console root access. Very unpractical, especially for a host system. Maybe consider reverting back this recent change for the Whonix-Host version? (see also Restrict root access) -> still to be discussed and decided
power-manager plugin + pulseaudio plugin -> FIXED (and audio working, at least in KVM)
The Whonix Host should be graphically differentiated from the Whonix-VMs. Maybe simply a different background image/color? -> still to be done
Somehow a user user was created during the build … FIXED
By default, the VMs do not start because the virtual disks are not set to readonly in virt-manager -> still in discussion (https://phabricator.whonix.org/T914)
As of now: Whonix-Gateway/Workstation virtualization using ISO file only works, but disks must be manually set to read-only in virt-manager AND booted in live-mode (expected behavior, but may be overwhelming/unpractical for end-user, at least needs documentation).
Same problem on the install target. Desired behavior: when booting in live-mode, set the disks to read-only (in their xml files, as their file permissions are already 0444). BUT on the install target change .qcow2 files permissions from 0444 to 0644 during the install process (0444 only needed for live ISO. Probably achievable using some Calamares tweaks/scripting to change the permissions when they are copied over. Needs some researches).
Currently the live system in ISO mode provides a live-user account with passwordless sudo rights -> can be fixed by addinglive-config.noroot to live ISO boot parameters (but then we need to change calamares polkit to allow its execution by sudoless user) -> still to be discussed and decided
No more new bugs to report as of now.
Small suggestion: add the “Show Desktop” button on the XFCE4-panel (minimize all windows immediately, very practical when you are overwhelmed with stuff, exists on Windows since ages). It is already installed, just needs to be added in the XFCE4-panel config file.
I will test on real hardware and see how it behaves.
Whonix-Host (Kicksecure) 18.104.22.168.7 booting from the live ISO file in KVM , showing a work session with both Whonix-Gateway and Whonix-Workstation running in live-mode ((nested virtualzation,Tor tab is within the Workstation) and the host system monitor. As expected, a solid amount of RAM is needed (already 5.6 GiB consumed)
Kicksecure and Whonix Host are independent projects.
Well, Whonix Host and Whonix VMs are based on Kicksecure, but that’s about it.
Kicksecure doesn’t focus on Tor / Whonix integration at all. It might come with Tor installed by default for secure network time synchronization, i.e. sdwdate. The ultimate goal is to move Kicksecure on its own domain name. This may or may never happen due to lack of resources. Depends on how much traction the project will get.
I think no - because then the user needs to have two different passwords.
sudo/root is now nicely sorted and documented here:
But why root login? Why not login as user and sudo su? What advantage does root login on virtual console give?
Settings disks to read-only when booted in live mode (i.e. ConditionKernelCommandLine=|boot=live) is actually implemented as per https://phabricator.whonix.org/T914#18825
It might not work though. To debug also see that ticket. Also perhaps run manually to see what the script does not or does wrong.
During Calamares install, the user is given the choice of having the same password for administrator user (root) and his newly created user.
My understanding is that when choosing same password, the newly created user is added to sudo group, if not, then he doesn’t have sudo rights. I need to verify this however.
As of now, no user can sudo, sudo su or su - it never works.
That could be great but I’m afraid that changing the permissions in life-mode will result in copying the entire files into RAM (we had this problem before if I remember correctly) before the permission change can be performed. Worth a try.
Sorry for my long absence, I was very busy lately. I hope that I will have more time in the coming days/weeks to pursue this matter. Hopefully we can have something ready before the end of the year…
Any help is welcome if someone has some time to spare
I’ll do a new build from scratch and see what remains to be done, as it’s been so long since I did the last one…
No worries. Yes, please move this forward. Looks like halfway done. Whonix still very much alive and kicking. Kept on merging lots of unrelated (security) enhancements lately. Let me know how things are going.