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.
Now I have a live user named test, who is part of groups libvirt and kvm (just for testing purposes).
While we are at it, we should probably also change the live user full name from Debian Live User to Whonix Live User? It is visible in the whisker menu, and probably other place ls as well (live-config.user-fullname= parameter)