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.
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.
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
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.
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?
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.
These packages could duplicate that package and then say in debian/controlReplaces: whonix-xfce-desktop-config. Lots of code duplication. Not great.
Or whonix-libvirt (or some other Whonix host package) could do config-package-devdisplace/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, 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.
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).
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).
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.
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]
Theming lacks arc-icons (currently using Adwaita icons, not so bad IMHO) → not an option, so fixed
B. still needs work
1. Virtual Machine Manager/KVM
New issue with virt-manager (both on ISO and install target): Error connecting to graphical console: Error opening Spice console, SpiceClientGTK missing → can be fixed by installing gir1.2-spiceclientgtk-3.0 and needed dependencies (apt install --no-install-recommends gir1.2-spiceclientgtk-3.0) (didn’t do a pull request yet as I don’t know exactly where it goes)
Does it work in EFI mode? Needs more testing → to be done
3. Whonix-Host install on HDD
at least one of the kernel hardening boot parameters somehow messes with the CPU detection on the host → to be done (needs further testing, see also Kernel Hardening - security-misc - #153 by Patrick)
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 - #64 by Patrick) → to be discussed
Somehow a user user was created during the build although it should be avoided at all costs (messes with live-user user config + is being copied over onto the host install) → to be verified/fixed (I am currently rebuilding a whonix-host machine to see if this error still happen. Didn’t do a pull request yet as I don’t know exactly what to change)
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)
@Patrick if you want to open new tasks on phabricator and assign me some, please be aware that I have just recreated an account (previous credentials lost): onion_knight2, waiting for your approval
Somehow a user user was created during the build although it should be avoided at all costs (messes with live-user user config + is being copied over onto the host install) -> to be verified/fixed (I am currently rebuilding a whonix-host machine to see if this error still happen. Didn’t do a pull request yet as I don’t know exactly what to change)
After rebuilding a Whonix-Host-15.0.0.3.6, I found the following: while testing the RAW file (not the ISO)
no home folder for user user was created during the build
BUT the file/etc/passwd contains a valid entry for user user, whose /home directory is created during first boot in persistent mode (along with Desktop, Downloads and Pictures directories, I guess copied from /etc/skel) user:x:1000:1000::/home/user:/bin/bash
If I remove this entry from the /etc/passwd file, no /home/user directory is created, and instead of the graphical session, the lightdm login page is loaded (expected behavior)
guess what, default user user password is… changeme -> inherited from Whonix
I guess all this is is faulty behavior and not on purpose?
Also, shouldn’t we remove the line autologin-user=user from /etc/lightdm/lightdm.conf (not as problematic, but still).
Account confirmed. As for assignment, I don’t know which tasks could be assigned which not. Please pick whatever you like to work on and then self-assign (if that is possible) or just leave a comment that you started working on it on the ticket.
Package live-config file /lib/live/config/0030-user-setup seems to be responsible for user creation? That script seems to have a lot parameters / options we can consider. It also does a lot stuff we need to understand. Can we consider to skip /lib/live/config/0030-user-setup and leave that to the existing implementation for greater simplicity and consistency (user user created everywhere the same as much as possible)? Looks like (by reading /lib/live/config/0030-user-setup) by setting LIVE_USERNAME=user we might be able to skip /lib/live/config/0030-user-setup. Untested. Could you try please?
Generally, should we use package live-config folder /lib/live/config/ as much or little as possible? We at least need an overview what /lib/live/config/ does to check if it compatible with what we want.
Not that I know of. spiceclientgtk used to be pulled automatically as a dep of the packages listed on the KVM wiki page. Could have been changed with Buster (but I had no way to know since I did an in place upgrade of an already installed system).
The existing implementation causes too many issues IMHO. What for instance if I want to install Whonix-Host with user user? It will conflict with the existing user + files might be copied over to the install target, unclean (/etc/passwd, /etc/group, maybe other files even?).
To allow a clean environment for Whonix-Host ISO+installer I think we need to completely skip the user creation part during the build.
From man live-config:
live-config.username=USERNAME | username=USERNAME
Allows one to set the username that gets created for autologin. The
default is 'user'.
→ by default, it already creates a user user. I don’t see the benefits of adding this parameter ourselves?
Two solutions:
Explicitly exclude unwanted components as boot parameters: live-config.nocomponents=COMPONENT1,COMPONENT2.… (from man live-config) (default behavior is loading all components in /lib/live/config)
"Shiping a locally modified live-config package or using dpkg-divert: (from man live-config):
Removing existing config components
It is not really possible to remove components itself in a sane way yet
without requiring either to ship a locally modified live-config package
or using dpkg-divert. However, the same can be achieved by disabling
the respective components through the live-config.nocomponents mecha‐
nism, see above. To avoid to always need specifying disabled components
through the boot parameter, a configuration file should be used, see
above.