Whonix Desktop Installer with Calamares - field report

HulaHoop · July 18, 2019, 12:46pm

@Patrick do I still need t change the guide?

Patrick · July 18, 2019, 12:55pm

Yes. Would be very helpful. Starting with minimal packages (Debian minimal or so) and then setting all up with --no-install-recommends.

HulaHoop · July 18, 2019, 12:58pm

Comapred the blaklisted modules with the loaded ones on my host and llc is needed for bridging in libvirt.

It is fetched as part of the collection. Do you know the reverse depends command so I can check it quickly?

Can you make (sanely) Whonix KVM work while sudo apt purge dnsmasq* ?

I remember trying that some time ago and this would break NAT networks.

HulaHoop · July 18, 2019, 1:03pm

OK it seems dnsmasq-base needes to be added explicitly for it to be fetched.

EDIT:

Nope. Seems it is included in the Whonix base install by default.

HulaHoop · July 18, 2019, 1:09pm

Here’s the suggested packages. I hesitate to exclude them because I don’t know what features we need rely on these packages. They are relatively few compared to the mandatory collection anyhow.

Suggested packages:
  augeas-doc wodim cdrkit-doc augeas-tools libdv-bin oss-compat libosinfo-l10n
  sidplay-base gstreamer1.0-plugins-bad libvirt-daemon-driver-storage-gluster
  libvirt-daemon-driver-storage-rbd libvirt-daemon-driver-storage-zfs numad
  auditd nfs-common open-iscsi radvd systemtap zfsutils libvisual-0.4-plugins
  python-cryptography-doc python-cryptography-vectors python-enum34-doc
  python-openssl-doc python-openssl-dbg python-socks python-ntlm
  python-dbus-doc python3-dbus-dbg samba vde2 qemu-block-extra sgabios
  debootstrap ssh-askpass gnome-keyring gir1.2-secret-1 python3-guestfs

Patrick · July 18, 2019, 1:31pm

reverse-depends dnsmasq-base

Shows:

Reverse-Recommends
==================
* libvirt-daemon-system
* lxc
* network-manager

Reverse-Depends
===============
* concordance-common
* dnsmasq
* mahimahi
* neutron-dhcp-agent

Try to remove the package and see what happens. Still enough time to abort. Also good to experiment in live mode. Then perhaps try to uninstall another package from that list instead to track further and further. Or uninstall and reinstall one by one using --no-install-recommends and see at which point something would pull the package.

HulaHoop:

Here’s the suggested packages. I hesitate to exclude them because I don’t know what features we need rely on these packages. They are relatively few compared to the mandatory collection anyhow.
Suggested packages:

Suggested packages are never installed by default. Only when using --install-suggests, which I saw never anyone using. This is only about Recommends:.

That list of Suggests: contains packages definitively to be avoided. Packages like gnome-keyring can cause other issues. Just not great to have any packages without really needing those.

As for Recommends: these should not be relied upon. Installation vs non-installation depends on which packages the user already has installed. Therefore this can lead to inconsistent / non-compareable results.

For example dnsmasq-base might recommend dnsmasq for no reason which could then interfere with host DNS. In worst case a world reachable port could be opened.

Another example for what mess it can create:
Installing git-all will delete some Whonix packages

More on why we need --no-install-recommends:
Debian Packages - Whonix

In conclusion we really need start with Debian minimal, then install with and without --no-install-recommends. Understanding the difference in packages being installed and having a basic understanding which each of this different packages would make.

By Debian policy, packages must not depend on any Recommends: being installed for secure configuration. It won’t be that difficult after all. Just some features might break when some package is missing which can be easily fixed when knowing the difference of which packages are missing.

Whonix base install? You mean inside VMs? I wouldn’t know what pulls it . Not existing in Qubes-Whonix. Try to purge it:

sudo apt purge dnsmasq*

It might be a leftover in upgraded images. If it is removable inside Whonix VMs, it should be removed. Just cruft. That could even break alternative DNS resolvers.
(MX / SRV / DNSSEC / any DNS requests over Tor / DNSCrypt) (dnsmasq-base not so much but dnsmasq might create an unwanted listener port.)

HulaHoop · July 18, 2019, 11:57pm

It must have been pulled by dino because a clean snapshot doesn’t have it.

This is not the case on my host where it is installed. I confirmed with netstat. Also the documentation on libvirt makes this clear that it is not configured in a way that exposes the system but bound only to specific libvirt interfaces.

Nuking it breaks ‘default’ and any VM relying on NAT virtual network to access the outside world. Bridged adapters are not available for most Laptops out there. so we must rely on it.

If I were to purge it, only the dnsmasq -base package would be removed. Nothing else.

All right good to know.

Patrick · July 19, 2019, 9:02am

Patrick · August 9, 2019, 2:41am

git tag 15.0.0.3.6-developers-only builds, boot fine, looks good at first look.
Preciously there were some issues with root/sudo in an intermediate development version in the VM version of Whonix. These are now fixed.

Some changes to how root/sudo works beginning with 15.0.0.3.6-developers-only: The default root account is locked. This is a purposeful security feature. See:

onion_knight · August 15, 2019, 11:44am

Sorry for low activity lately, much to do IRL.
Will try a new build and hopefully will have more time to pursue this project.

onion_knight · August 15, 2019, 12:04pm

I noticed I did a git checkout 15.0.0.3.6-developers-only but it’s building 15.0.0.3.9-27 regardless… Any idea why?

Patrick · August 15, 2019, 12:35pm

Looking into that now. Will try to reproduce.

Patrick · August 15, 2019, 12:55pm

These are the commands I am using. (Taken from Build and Update Whonix from Source Code)

git clone --jobs=4 --recursive https://github.com/Whonix/Whonix
cd Whonix
git verify-tag 15.0.0.3.6-developers-only
git checkout 15.0.0.3.6-developers-only
git describe

(git describe just now added as a test.)

git describe should output

15.0.0.3.6-developers-only

sudo ~/Whonix/whonix_build --flavor whonix-gateway-xfce --target virtualbox --build

Build output should contain pretty early (copy to text editor and search perhaps):

INFO: Variable anon_dist_build_version was unset. Auto detected. Set to: 15.0.0.3.6

Later on the build output should include:

true '/home/user/Whonix/help-steps/git_sanity_test INFO: git_tag_nearest: 15.0.0.3.6-developers-only ’

true '/home/user/Whonix/help-steps/git_sanity_test INFO: git_tag_current: 15.0.0.3.6-developers-only

Building form a non-tagged release is actually deliberately protected against and made a tiny bit more difficult. Requires adding:

--allow-untagged true --allow-uncommitted true

(But this is mentioned in the error message when that happens.)

Build would actually fail, but also advice why.

true ‘---------------------------------------------------------------------’

true '/home/user/Whonix/help-steps/git_sanity_test ERROR: Git reports uncommitted changes! ’

true '/home/user/Whonix/help-steps/git_sanity_test INFO: (And you are not using --allow-uncommitted true, which you also should not do for security reasons, unless you are a developer or advanced user and know what you are doing. Such as in case you added custom code.) ’

git_sanity_test_hint

true '/home/user/Whonix/help-steps/git_sanity_test INFO: (As a developer or advanced user you might want to use:)
–allow-untagged true --allow-uncommitted true
’

true '/home/user/Whonix/help-steps/git_sanity_test INFO: Running “git status” for your convenience. ’

git status
HEAD detached at 15.0.0.3.6-developers-only
Untracked files:
(use “git add …” to include in what will be committed)

packages/binaries-freedom/
packages/kicksecure-base-files/

nothing added to commit but untracked files present (use “git add” to track)

true '/home/user/Whonix/help-steps/git_sanity_test INFO: Running git “clean -d --force --force --dry-run” for your convenience. ’

git clean -d --force --force --dry-run
Would remove packages/binaries-freedom/
Would remove packages/kicksecure-base-files/

true '/home/user/Whonix/help-steps/git_sanity_test You most likely like to run:
/home/user/Whonix/help-steps/cleanup-files
or if you know what you are doing:
git clean -d --force --force
git reset --hard
’

true ‘---------------------------------------------------------------------’

error ‘Uncommitted changes! See above!’

echo ‘############################################################’
############################################################

echo ‘ERROR: Uncommitted changes! See above!’
ERROR: Uncommitted changes! See above!

echo ‘############################################################’
############################################################

error_ ‘See above! (There should be a bold, red message surrounded by blue hashtags (#).)’
pre: line 30: error_: command not found

git clean -d --force --force solves that.

Btw just finished testing Whonix git tag 15.0.0.3.9 which is uploaded already with a call for testers coming soon.

(Also has such an extraneous folder.)

If that does not work for you, please paste the commands you’re using here. Or post the output of a whole build until around the git_tag_current line.

onion_knight · August 15, 2019, 2:36pm

Thanks. Building 15.0.0.3.6-developers-only now.

Patrick · August 15, 2019, 3:26pm

Btw it comes with passwordless recovery / emergency mode. Hopefully this release won’t block you from gaining root. This is well tested in Whonix VM VirtualBox builds. When you’r ready to test… Keep your time… Still having gain root issues?

In case there are still gain root issues, I could invent a kernel boot parameter adminrootcreate or so which creates user admin with group sudo membership and default password changeme for debugging purposes in next build.

Also news, root account disabled by default:

onion_knight · August 19, 2019, 1:04pm

Sorry for previous post, I pushed the “reply” button too fast.

Thanks @Patrick, I have successfully built a Whonix-Host-15.0.0.3.6 using the following commands:

git clone --jobs=4 --recursive https://github.com/Whonix/Whonix
cd Whonix
git verify-tag 15.0.0.3.6-developers-only
git checkout 15.0.0.3.6-developers-only
git describe
sudo ~/Whonix/whonix_build  --build --redistribute --target iso --flavor whonix-host-xfce --freedom false --allow-untagged true --allow-uncommitted true

Test Report Whonix-Host-XFCE-15.0.0.3.6 ISO and Whonix-Host-15.0.0.3.6 on HDD

1. Virtual Machine Manager/KVM

As reported earlier, KVM networking does not work because one of the blacklisted network protocols in /etc/modprobe.d/uncommon-network-protocols.conf is needed. After further researches, I have found which one: install llc /bin/true:
lsmod | grep llc
llc 16384 2 bridge,stp
See my pull request on GitHub
By default, the VMs do not start because the virtual disks are not set to readonly. This is only needed when using the ISO though. Might stay this way as long as the user is correctly advised to change to set the disk to readonly mode.
By default, the VMs do no start until the CPU configuration is set to “Copy host CPU configuration”, which is expected in KVM, but also happened when testing on real hardware (both using the ISO and the installed version). Might be related to my specific hardware though.
Even with these settings and contrary to previous versions, I was not able to successfully start the VMs, both using the ISO and the installed version of Whonix-Host, both in KVM and on real hardware! The error is now: Error starting domain: unsupported configuration: host doesn't support paravirtual spinlocks
I have no idea what causes that and what it means. Needs further exploration.

2. Calamares Installer

Needs correct branding (see also: Whonix Host Calamares Branding Suggestion - #3 by onion_knight. Just a reminder. Probably better to tackle this issue later when everything else works.)
Install works fine on BIOS legacy systems (tested both in KVM and real harware)
While the ISO boots fine in EFI mode, my install attempt in EFI mode failed. Needs further testing.

3. Whonix-Host install on HDD

Grub menu also provides a Debian-Live option, although it does not work (results in kernel panic since live packages are removed during the installation part and are not part of the installed system). Grub menu needs to be fixed accordingly in the installed machine (must be somewhere in the Calamares modules). Similarly, the persistent/live icons must be removed from the installed version.
As expected, the installed system has no virtual console root access. I find it very unpractical, especially for a host system. Maybe consider reverting back this recent change for the Whonix-Host version?

4. Miscellaneous

Currently the live system in ISO mode provides a live-user account with passwordless sudo rights, i.e. it overrides the current disabled root account configuration. Might be a bug or a feature depending on the point of view.
Theming lacks arc-icons (currently using Adwaita icons, not so bad IMHO). Probably normal if not yet implemented in Whonix? Cosmetic issue, not a big deal.
As we are dealing with a host system (be it ISO or HDD install), it would be nice to have a power-manager plugin on the panel (xfce4-power-manager), something expected on a laptop for instance, I think this package does the trick (I must retest it on laptop hardware):

root@whonix-host-15:~# apt install xfce4-power-manager Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: xfce4-power-manager-data xfce4-power-manager-plugins The following NEW packages will be installed: xfce4-power-manager xfce4-power-manager-data xfce4-power-manager-plugins 0 upgraded, 3 newly installed, 0 to remove and 7 not upgraded. Need to get 1,016 kB of archives. After this operation, 4,487 kB of additional disk space will be used. Do you want to continue? [Y/n] y
same thing with pulseaudio plugin (already installed, just needs to be added in the panel tray)
The Whonix Host should be graphically differentiated from the Whonix-VMs. Maybe simply a different background image/color?

Screenshot from the installed Whonix-Host-XFCE-15.0.0.3.6 install (on KVM):
“Vanilla” install, only added xfce4-power-manager plugin and pulseaudio plugin and remove the live/persistent indicator on the panel

Patrick · August 19, 2019, 1:47pm