[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Whonix Desktop Installer with Calamares - field report

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.

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:
https://www.whonix.org/wiki/Whonix_Debian_Packages#Technical_Stuff

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.)

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.

1 Like
1 Like

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:

1 Like

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

2 Likes

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?

1 Like

Looking into that now. Will try to reproduce.

These are the commands I am using. (Taken from https://www.whonix.org/wiki/Dev/Build_Documentation/15_full)

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.

1 Like

Thanks. Building 15.0.0.3.6-developers-only now.

1 Like

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:

1 Like

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. 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

2 Likes

More answers soon.

This is something that users shouldn’t use but useful during development since you can modify files and still build from “unclean” state.

Merged.

Ticket, discussion and possible solution in https://phabricator.whonix.org/T914.

Awesome work!

Need to split this into many smaller tickets to make this manageable. I am loosing track if too many things are in one place. Specifically the stuff that can be reassigned to @HulaHoop or me.

VMs do no start until the CPU configuration is set to “Copy host CPU configuration”

Error starting domain: unsupported configuration: host doesn't support paravirtual spinlocks

Awesome!

I don’t know much about EFI booting yet and don’t have hardware to test.

packages that we might need:

(quite possibly) https://packages.debian.org/buster/shim-signed

(less likely but perhaps useful anyhow) https://packages.debian.org/buster/refind

Related, more links here:

posted here Restrict root access

Considered a bug. Superuser hardening is specifically useful for live mode. Even more useful later on when optional non-root boot gets added.

(multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot)

Likely package live-config file /lib/live/config/0040-sudo is causing this. Also package live-config is doing a lot other stuff which we need to understand. Or get rid of live-config package. Had a similar issue due to live-config earlier I have written about here.

Can we just leave out the live-config package or what do we rely on it for?

Thanks for your feedback.
Will try to address your questions later (I need to test more).
Just wanted to add an important edit: in both Whonix-Install and Whonix-ISO there is a user account that has been created during build (with/home/user/).
This was not the case before as if I remember correctly when building an --iso no user was created to avoid this issue.
Was there any change since May or June regarding this specific issue?

1 Like

arc-icons not in use due to unavailable from packages.debian.org

that is:

just now followed up here:

Booting the installed Whonix Host into Live mode would be a great feature. I am using grub-live for a Debian host machine. Should be possible to fix that.

I get that done, created https://phabricator.whonix.org/T928 for it.

Should be sorted in next git tag. 15.0.0.4.0-developers-only (upcoming)
Sorted that in https://github.com/Whonix/whonix-xfce-desktop-config/commit/12dad74b906c675f834fa6431a3892e7dc499128 for Whonix VMs so śhould also work on Whonix Host since also using package whonix-xfce-desktop-config.

That would be very good. I also want to differentiate Whonix VMs gateway vs workstation as well as differentiate from the host. Technical challenge:

Package package whonix-xfce-desktop-config owns /etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. As per Debian dpkg default one file can only be owned by one pacakge.

I wouldn’t know how to cleanly stack these packages. I.e. how to add yet another package on top that only ships one different config file?

[1] whonix-xfce-workstation-config
[2] whonix-xfce-host-config

These packages could duplicate that package and then say in debian/control Replaces: whonix-xfce-desktop-config. Lots of code duplication. Not great.

Or whonix-libvirt (or some other Whonix host package) could do config-package-dev displace /etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. Better but still one fully duplicated config file.

Any other way to just change the background image? A command line command that runs one time after first login? Is it possible to change the background image on the command line?

Ok, understood.

Ok, should be possible, maybe by not removing live-config packages from the install target. Trying now.

Should be possible, but sounds hackish.

EDIT: if I remember well, Whonix 13 already had different backgrounds and general appearances for Gateway and Workstation. Would it be possible to reproduce this with more or less the same code?

EDIT2: not removing the live-boot packages from the target install allows for a live-boot of the host. See my pull request on github.

1 Like

It is possible to boot in live-mode without root account by appending live-config.noroot as a boot parameter (although in my test, it only works if I first remove the user user installed during the build and reburn the ISO). The problem is that Calamares needs administrator rights to run by default, unless we change this rule in its polkit settings (/usr/share/polkit-1/actions/com.github.calamares.calamares.policy).

My understanding is that it is useful for a lot of configuration files that allow for fine customization such as booting without root privileges. See also https://manpages.debian.org/buster/live-config-doc/live-config.7.en.html:

live-config contains the components that configure a live system during the boot process (late userspace).

It seems at least useful for the ISO version. I will try to remove it entirely from the RAW file before the ISO step and see how it goes.

EDIT: I don’t think it’s a good idea to remove altogether live-config. Currently, we need it during the ISO stage to create a live-user which is a member of libvirt and kvm groups (live-config.user-default-groups=libvirt,kvm) + we can use it to disable passwordless sudo live-user and root account (see above).

1 Like

onion_knight via Whonix Forum:

EDIT: if I remember well, Whonix 13 already had different backgrounds and general appearances for Gateway and Workstation. Would it be possible to reproduce this with more or less the same code?

Whonix 13 was KDE based. KDE supports environment variable
XDG_CONFIG_DIRS. These are stackable ad infinitum.

(


)

XFCE does not support environment variable XDG_CONFIG_DIRS /
configuration folder stacking.

New issue with virt-manager (both on ISO and install target):

Error connecting to graphical console: Error opening Spice console, SpiceClientGTK missing

The VM is running, but cannot be viewed with Spice display.

Installing gir1.2-spiceclientgtk-3.0 and needed dependencies solves the problem (didn’t have this problem before, was this package dropped in a latest Whonix release?)

apt install --no-install-recommends gir1.2-spiceclientgtk-3.0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  gir1.2-spiceclientglib-2.0 libphodav-2.0-0 libphodav-2.0-common
  libspice-client-glib-2.0-8 libspice-client-gtk-3.0-5 libusbredirhost1
  spice-client-glib-usb-acl-helper
Suggested packages:
  gstreamer1.0-plugins-bad gstreamer1.0-plugins-base gstreamer1.0-plugins-good
  gstreamer1.0-libav
The following NEW packages will be installed:
  gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 libphodav-2.0-0
  libphodav-2.0-common libspice-client-glib-2.0-8 libspice-client-gtk-3.0-5
  libusbredirhost1 spice-client-glib-usb-acl-helper
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,559 kB of archives.
After this operation, 2,957 kB of additional disk space will be used.
Do you want to continue? [Y/n]
1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]