Whonix-Host Operating System (OS) ISO

The following packages are also needed for “Whonix-Host” (and probably also Kicksecure?):

x11-xserver-utils
"If x11-xserver-utils is not installed nothing happens after clicking on
an option in the xfce logout dialogue. If logout is clicked again the
message: Failed to log out. Session manager must be in idle state when requesting a shutdown comes up.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902137
→ btw seems to be already installed by default on Whonix-Gateway/Workstation (at least the versions I have here)

gvfs
" GVfs is a userspace virtual filesystem implementation for GIO (a library available in GLib). GVfs comes with a set of backends, including trash support, SFTP, SMB, HTTP, DAV, and many others. GVfs also contains modules for GIO that implement volume monitors and persistent metadata storage. There is also FUSE support that provides limited access to the GVfs filesystems for applications not using GIO."
https://wiki.gnome.org/Projects/gvfs
→ btw seems to be already installed by default on Whonix-Gateway/Workstation (at least the versions I have here)

1 Like

Git tag 15.0.0.9.3-developers-only builds without build errors.

sudo -E ./whonix_build --flavor whonix-host-xfce --build --repo true --target iso --freedom false --allow-untagged true --allow-uncommitted true --remote-derivative-packages true

Though, the latest build parameter

--remote-derivative-packages true

is for debugging (faster builds) only and has some caveats. (Whonix build script now optionally supports installing packages from Whonix remote repository rather than building packages locally) Didn’t try without --remote-derivative-packages true yet (locally build packages) but chances are good it would work too.

1 Like

Yay, even boots a desktop and has functional network. sudo su also functional.

2 Likes

Awesome!

In live mode?

1 Like

Yes. I booted the iso (plugged it into VirtualBox).

This might make make development a bit more easy:
dsudo - default password sudo

Related, Whonix Host and Kicksecure need the proper host network configuration needs the proper packages and configuration files:
Kicksecure Network Configuration

After some manual modifications (see above), I successfully built a 15.0.0.9-developpers-only ISO that successfully installed a “Whonix-Host” KVM virtual machine…

At first glance I have the impression that since my last tries (end of summer) there are a lot of “regressions” in terms of default desktop support (missing packages such as x11-xserver-utils, gvfs, pavucontrol… and other ones?), is it on purpose?

Next step: I will try a new build 15.0.0.9.3-developers-only and do a more in-depth report.

1 Like

Not on purpose. No host development since.

onion_knight via Whonix Forum:

The following packages are also needed for “Whonix-Host” (and probably also Kicksecure?):

x11-xserver-utils
"If x11-xserver-utils is not installed nothing happens after clicking on
an option in the xfce logout dialogue. If logout is clicked again the
message: Failed to log out. Session manager must be in idle state when requesting a shutdown comes up.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902137

gvfs
" GVfs is a userspace virtual filesystem implementation for GIO (a library available in GLib). GVfs comes with a set of backends, including trash support, SFTP, SMB, HTTP, DAV, and many others. GVfs also contains modules for GIO that implement volume monitors and persistent metadata storage. There is also FUSE support that provides limited access to the GVfs filesystems for applications not using GIO."
Projects/gvfs - GNOME Wiki!
→ btw seems to be already installed by default on Whonix-Gateway/Workstation (at least the versions I have here)

Will come in Whonix 15.0.0.9.4 and above.

onion_knight via Whonix Forum:

…, pavucontrol

At first glance I have the impression that since my last tries (end of
summer) there are a lot of “regressions” in terms of default desktop support

Unrelated refactoring broke these things since nobody looked at the
effects on Kicksecure Host or Whonix Host.

(missing packages such as x11-xserver-utils, gvfs,
pavucontrol… and other ones?), is it on purpose?

The mentioned ones should be fixed in git master.

Great, thanks!

I’ve just successfully built 15.0.0.9.3-developers-only with

sudo -E ./whonix_build --flavor whonix-host-xfce --build --repo true --target iso --freedom false --allow-untagged true --allow-uncommitted true --remote-derivative-packages true

Booting the ISO works, however it ends at the lightdm login page (no auto-login or no live user creation). I guess it’s because you removed live-config package.

Installing live-config and reburning the ISO solved the problem, as expected.

2 Likes

Other bug, still on 15.0.0.9.3:

Whonix VM disks are NOT set to read-only. It is however required to run them in live mode.

This command (see above, Whonix host operating system - #79 by Patrick) does the trick:

virt-xml Whonix-Workstation --edit --disk readonly=on

This command should be added and run during Whonix-Host libvirt configuration. Is it done here now?
https://github.com/Whonix/whonix-libvirt/blob/master/usr/lib/whonix-libvirt/install

2 Likes

It’s implemented here but maybe not working.

Possible error causes:

  • It required kernel parameter boot=live to be set. Is it set?
  • Which systemd units are required by virt-xml? Maybe it needs similar After= as whonix-libvirt-install.service?

YES

No idea :slight_smile:

1 Like

Let’s make that work without live-config for reasons mentioned above. Should be very doable since Whonix VMs use autologin too.

whonix-xfce-desktop-config should be installed already?
whonix-xfce-desktop-config ships whonix-autologin.conf, therefore there should be autologin?

User user exists (as created by anon-base-files). Do we still require a separate live user?

virt-xml maybe not but before it runs virsh and virsh might require these services. Added:

Meanwhile you could tr

sudo systemctl status whonix-libvirt-set-live-to-readonly

(Unrelated but also important.)

sudo systemctl status whonix-libvirt-install

and

sudo systemctl restart whonix-libvirt-set-live-to-readonly

And check journal?

sudo journalctl -u whonix-libvirt-set-live-to-readonly
sudo journalctl -u whonix-libvirt-install

And also perhaps check whole journal?

sudo journalctl

(Perhaps redirect to file for more convenient viewing.)

I don’t understand for what reasons exactly. I don’t know how make it work without it.

No, there shouldn’t be a user user! It had been removed on purpose back then, for various reasons, the most important being that during Calamares install it is being copied over to the newly installed system. Very bad.

And yes you’re right, user user seems to be created again during the Whonix-Host build, but it shouldn’t be that way. It was removed a long time ago.

The good thing about live-config and user-setup is that it takes care of the live-user creation at boot time and its behavior is very easily customizable via simple kernel boot flags

1 Like

I reverted it in last few days.

User user creation, sudo, su, groups got rather complex. Full story:

It’s hard to have live-config create the live user and at the same time have security-misc installed. That’s where the build breaking bug “no user is a member of group sudo” bug came from.

Can we configure calamares to:

  1. skip copying files from live iso home user to installed system
  2. skip calamares user creation (leave that to anon-base-files)

?

Otherwise anon-base-files, user user creation, security-misc permission hardening, VMs, live user, VM user gets a hard to resolve labyrinth.

  1. Calamares being quite customizable I guess we could, but unless we remove its account completely, user user won’t go away after the installation.

  2. We could probably also skip calamares user creation, but then what is the purpose of an installer if no user can be created during installation?

Coming back from a long break I had no idea of the changes made that rendered the creation of a user user a prerequisite for security-misc. It seems very complex and unusual to me to have a user user already set up at this stage. Would be much cleaner and easier if we could revert back to the no user installed scenario (which is how all debian-base live distros behave by default as far as I know, regardless of the installer type):

no user user → live-boot with live-user → creation of a final user account is done during installation as expected (Calamares)

I guess calamares allows us to somehow drop a script which then removes any unwanted folders.

Purpose of installer is:

  • transferring iso contents to hdd
  • partition disk
  • encrypt disk
  • install bootloader
  • sort out BIOS vs EFI boot maybe
  • sort out Secure Boot maybe
  • not sure about other stuff such as keyboard configuration, system language selection
  • more common user experience (similar other Linux distributions installation)