Whonix-Host Operating System (OS) ISO

Great. building now.

OK, I’ll try that. I can foresee problems with Calamares installer that needs root password access. We’ll figure that later.

Yes, I receive e-mail notifications. I’ll have a look.

1 Like

Actually, we don’t use this file anymore in our current Calamares install sequence (module users is skipped), thus I guess no need to change it.

Currently when booting Whonix-Host iso (and all previous recent successful builds), user user has full sudo rights (although not in sudo group). This behavior is then reproduced in the Whonix-Host installed version. I gather this not the expected behavior as per current “restricted root” policy? What should be the default expected behavior regarding sudo/root/admin rights in Kicksecure/Whonix GW-WS?

Regarding last merged pull requests (branding), everything seems to work as intended (see screenshots below).

Still needs fixing/considering

  • Whonix VM disk images are still not set in ro mode
  • We should have auto-login enabled for user user (unpractical to log in when booting an ISO file)
  • We need to replace Kicksecure references by Whonix-Host everywhere (I am thinking /etc/motd, grub, anything else?).
  • Test on real hardware (both EFI/BIOS)…
  • Get rid of the default XFCE4 desktop image (replace with simple color?), add some Desktop icons (cosmetic changes, not urgent)

Some screenshots:

  1. Booting on Whonix-Host Live ISO, showing desktop, Install Whonix-Host icon, as well as a terminal displaying user user root access

  2. Clicking on Install Whonix-Host icon launches Calamares. It needs sudo rights to proceed.

  3. Whonix-Host Installer (Calamares) Welcome page

  4. Whonix-Host Installer (Calamares), installing in progress (full-disk encryption)



Alright. Let’s change that anyhow please to avoid confusion and maybe just in case?

This is expected. To elaborate, when user user runs “sudo something” the user should be prompted for the password. If the password is correct, the command would run as root.

This might change in future when multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode is implemented.

Your screenshot shows that running id that user user is a member of group sudo. This is expected as of now. Same as in Whonix VMs.

Untrusted Root - improve Security by Restricting Root is a development goal but not yet implemented.

Whonix (or Kicksecure) Host for now same as gw/ws VMs.



Makes me wonder if whonix-libvirt is the correct place to implement Whonix calamares settings.

whonix-libvirt.hide currently hides /etc/lightdm/lightdm.conf.d/whonix-autologin.conf. Therefore disables autologin.

  • Whonix-Host installed should not have autologin. That’s why above line.
  • Whonix-Host iso should have autologin.

These are somewhat conflicting goals. Debian solves that by uninstalling package calamares-settings-debian at the end of calamares. We can’t do that because whonix-libvirt does other things which still need to be done in Whonix-Host installed.

Solution 1) Have a systemd unit file that detects being run from iso that creates the required file to auto login.

Solution 2) a separate package calamares-settings-whonix which is only installed on Whonix-Host iso but not in Whonix-Host installed.

What do you think?

There’s a package whonix-base-files for that already. That’s likely missing in Whonix-Host.

That’s because Whonix-Host does not depend yet on whonix-shared-packages-dependencies-cli


  • Pre-Depends: whonix-legacy
  • Depends: whonix-base-files, anon-apt-sources-list, whonix-firewall, whonixsetup,

That’s because:

Fixed in git master just now:


Ok, done, but untested.

Ok, so nothing wrong and nothing to do. Great :slight_smile:

Yes, you are right. Oversight from me. Cool.

OK, let me investigate this. I’ll follow your instructions.

I think that the best option would be probably to have our own package calamares-settings-whonix and put there only the Calamares config files that we need. BUT: I have no idea how hard and sustainable it is in terms of maintainability, etc. I couldn’t do it myself.

But anyway where did you see that calamares-settings-debian took care of auto-login? My understanding is that it was taken care of by live-config default settings, and broke when we removed that package. We could however add /etc/lightdm/lightdm.conf.d/whonix-autologin.conf in our hypothetical calamares-settings-whonix package which would be uninstalled at the end of calamares installer.


1 Like

Would you like to move calamares settings to its own git repository (authorship git history) or shall I do that?

Yes. (Just filename needs to differ to avoid package conflict.)

Please do it :slight_smile:

1 Like

Done: GitHub - Kicksecure/live-config-dist
(Used a more generic package name so this package can be used for both Whonix, Kicksecure, Calamares and anything else that should only be done when booting the ISO.)

  • install live-config-dist during build process
  • uninstall live-config-dist package by calamares at the end
  • Whonix-Host ISO autologin
  • Whonix-Host installed no-autologin
  • allow running calamares without sudo password entry

Untested. Could you please have a look at the commit history?

1 Like


Do you mean testing a new build with these commits?

1 Like

That would be good but not what I meant. If that’s possible without a new git tag yet.

I meant looking at list of commits here
Commits · Kicksecure/live-config-dist · GitHub
then clicking each and see if something looks wrong or just to stay up to date.

In the meantime I launched a new build

Breaks at 1700 install packages:

The following packages have unmet dependencies:
 whonix-host-xfce-kvm-nonfreedom : Depends: whonix-host-xfce-kvm-freedom but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
1 Like

There must be more apt errors earlier when trying to install whonix-host-xfce-kvm-freedom or earlier than that.

Looking into this now.

That build issue was a bit tricky to identify and fix. whonix-base-files couldn’t be installed because it couldn’t replace kicksecure-base-files.

Build should be fixed in

Also thanks to travis.debian.net I might be finally able to set up a CI to detect such issues automated, faster in future.

Great! I will try to build it again. Regarding your commits history it seems fine to me, but I prefer to test a new iso build.

1 Like

Build seems fine. I was tagged Whonix-Host-XFCE- I don’t know why?
Juste a small fix for the installer desktop icon:

I will try to investigate this read-only bug with the VMs later.

1 Like


I deliberately removed as many mentions of hardcoded Whonix strings. Maybe we could re-name the file instead? The idea is that some Kicksecure package needs to modify only a minimal amount of files and voila, we have a Kicksecure installer too.

Most likely you build from git master in that case. If you git fetch/merge Whonix/Whonix then you’re a few commits ahead of the latest git tag. I deliberately added years ago the resulting files to contain the git commit in such cases to distinguish between builds from “real git tags” vs “something not git tagged”. Try running git describe in Whonix main source code folder. Similar to usual VM build instruction son how to checkout a specific tag and make sure it’s really used (git describe).

Yes, better then to rename live-config-dist/usr/share/pixmaps/install-whonix-host.png at master · Kicksecure/live-config-dist · GitHub to “install-host.png”.

1 Like

Regarding read-only: see my comment here

1 Like

While testing Whonix-Host-XFCE- I realized that it doesn’t have lvm support. Meaning it cannot manage encrypted disks with " LVM on LUKS" method. I strongly suggest adding package lvm2.

1 Like



   $CHROOT chmod -v -R 444 "/var/lib/libvirt/images/Whonix-Gateway.qcow2"
   $CHROOT chmod -v -R 444 "/var/lib/libvirt/images/Whonix-Workstation.qcow2"

chmod 444 meaning read allowed for owner, group, public.
(As per https://chmod-calculator.com/.)

Would chmod 440 (public cannot read the images) be better? In other words, why should all users on the system be able to read these images? Or is that the default?

I also find octal hard to work with. The following is much easier to understand:

  • chmod u (user/owner)
  • chmod g (group)
  • chmod o (others)

Therefore changed from octal to symbolic:

   $CHROOT chmod --verbose --recursive ugo-r "/var/lib/libvirt/images/Whonix-Gateway.qcow2"
   $CHROOT chmod --verbose --recursive ugo-r "/var/lib/libvirt/images/Whonix-Workstation.qcow2"

This is related to fixing ⚓ T914 Whonix Host Live - enable KVM readonly mode - virt-xml vm-name --edit --disk readonly=on.