Whonix Desktop Installer with Calamares - field report

[Patrick]

@onion_knight

Problem: shouldn’t we need a complete new branding now that Whonix-Host has been officially relabeled “Kicksecure”?

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.

Kicksecure - Secure by Default Operating System

@onion_knight

Shouldn’t we be installing Kicksecure on the install target instead of generic “Whonix-Host”?

Therefore, no.

@onion_knight

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

I think no - because then the user needs to have two different passwords.

sudo/root is now nicely sorted and documented here:

Safely Use Root Commands

root login can be enabled by the user as per:
Safely Use Root Commands

But why root login? Why not login as user and sudo su? What advantage does root login on virtual console give?

@onion_knight

By default, the VMs do not start because the virtual disks are not set to readonly in virt-manager → still in discussion (⚓ T914 Whonix Host Live - enable KVM readonly mode - virt-xml vm-name --edit --disk readonly=on)

Settings disks to read-only when booted in live mode (i.e. ConditionKernelCommandLine=|boot=live) is actually implemented as per ⚓ T914 Whonix Host Live - enable KVM readonly mode - virt-xml vm-name --edit --disk readonly=on
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.

sudo /usr/lib/whonix-libvirt/live-mode-to-read-only

@onion_knight

BUT on the install target change .qcow2 files permissions from 0444 to 0644 during the install process

This could be done during the boot process. Another systemd unit file. Similar to that commit enable readonly for KVM disks if kernel command line includes boot=live · Kicksecure/libvirt-dist@bb7773e · GitHub

Using ConditionKernelCommandLine=!boot=live - i.e. do not do that in when kernel boot parameter includes boot=live.

Or we drop ConditionKernelCommandLine from the systemd unit file and let the script handle chmod change depending on

if grep -qs "boot=live" /proc/cmdline; then
   ## live mode
   true "do things for live mode"
else
   ## persistent mode
   true "do things for persistent mode"
fi

I can implement that if you like.

But are you sure chmod permissions from 0444 to 0644 is really useful? Once ⚓ T914 Whonix Host Live - enable KVM readonly mode - virt-xml vm-name --edit --disk readonly=on is fully working, is that still required?

@onion_knight

Currently the live system in ISO mode provides a live-user account with passwordless sudo rights → can be fixed by adding live-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

Not passwordless sudo since that circumvnets the security enhancements made through Restrict root access / Safely Use Root Commands.

@onion_knight

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.

Yes, why not.