Whonix-Host Operating System (OS) ISO

YES

No idea :slight_smile:

1 Like

Let’s make that work without live-config for reasons mentioned above. Should be very doable since Whonix VMs use autologin too.

whonix-xfce-desktop-config should be installed already?
whonix-xfce-desktop-config ships whonix-autologin.conf, therefore there should be autologin?

User user exists (as created by anon-base-files). Do we still require a separate live user?

virt-xml maybe not but before it runs virsh and virsh might require these services. Added:

Meanwhile you could tr

sudo systemctl status whonix-libvirt-set-live-to-readonly

(Unrelated but also important.)

sudo systemctl status whonix-libvirt-install

and

sudo systemctl restart whonix-libvirt-set-live-to-readonly

And check journal?

sudo journalctl -u whonix-libvirt-set-live-to-readonly
sudo journalctl -u whonix-libvirt-install

And also perhaps check whole journal?

sudo journalctl

(Perhaps redirect to file for more convenient viewing.)

I don’t understand for what reasons exactly. I don’t know how make it work without it.

No, there shouldn’t be a user user! It had been removed on purpose back then, for various reasons, the most important being that during Calamares install it is being copied over to the newly installed system. Very bad.

And yes you’re right, user user seems to be created again during the Whonix-Host build, but it shouldn’t be that way. It was removed a long time ago.

The good thing about live-config and user-setup is that it takes care of the live-user creation at boot time and its behavior is very easily customizable via simple kernel boot flags

1 Like

I reverted it in last few days.

User user creation, sudo, su, groups got rather complex. Full story:

It’s hard to have live-config create the live user and at the same time have security-misc installed. That’s where the build breaking bug “no user is a member of group sudo” bug came from.

Can we configure calamares to:

  1. skip copying files from live iso home user to installed system
  2. skip calamares user creation (leave that to anon-base-files)

?

Otherwise anon-base-files, user user creation, security-misc permission hardening, VMs, live user, VM user gets a hard to resolve labyrinth.

  1. Calamares being quite customizable I guess we could, but unless we remove its account completely, user user won’t go away after the installation.

  2. We could probably also skip calamares user creation, but then what is the purpose of an installer if no user can be created during installation?

Coming back from a long break I had no idea of the changes made that rendered the creation of a user user a prerequisite for security-misc. It seems very complex and unusual to me to have a user user already set up at this stage. Would be much cleaner and easier if we could revert back to the no user installed scenario (which is how all debian-base live distros behave by default as far as I know, regardless of the installer type):

no user user → live-boot with live-user → creation of a final user account is done during installation as expected (Calamares)

I guess calamares allows us to somehow drop a script which then removes any unwanted folders.

Purpose of installer is:

  • transferring iso contents to hdd
  • partition disk
  • encrypt disk
  • install bootloader
  • sort out BIOS vs EFI boot maybe
  • sort out Secure Boot maybe
  • not sure about other stuff such as keyboard configuration, system language selection
  • more common user experience (similar other Linux distributions installation)

In security-misc we’re applying a lot security hardening configurations which are usually only mentioned in security guides.

Leaving that to users, security guides is a broken concept:

It seems very complex and unusual to me to have a user user already set up at this stage

Indeed. Though, we might be the first distribution to apply such security hardening by default.

That would be hard. We’d have to change security-misc implementation somehow. security-misc currently implements these things hopefully as easy and declarative as possible.

We also want that same security hardening when booting in live mode. And re-implementing it with live-config seems harder.

All right, so what do you suggest to do? Keep the user user?

1 Like

I suggest:

  1. skip copying files from live iso home user to installed system (of if that is not possible use a script to remove any unwanted files either during calamares or during first boot)
  2. skip calamares user creation question (leave that to anon-base-files)

…if that is possible.

Related questions:

How does calamares magic work anyhow? Does is something like debootstrap? Does it do sudo apt install whonix-host-xfce-kvm-nonfreedom inside chroot? (That would actually be the cleanest.) Or does it somehow copy from somewhere to somewhere?

Does calamares require networking?

related diff 15.0.0.8.9-developers-only…15.0.0.9.4-developers-only

Comparing 2fc6fc5318665db8bfb697d7d6b71495c7c8d229...c3640b4478b857ba36317a51eb08e834e75d7670 ¡ Kicksecure/libvirt-dist ¡ GitHub

So that would mean no user creation question during the installing process? Like say I would want to create a user John with the installer, I wouldn’t be able to do so? What user will I have on first boot on the installed version then? How is anon-base-files supposed to take care of that? I don’t get it.

To the best of my knowledge it can do both (first copies files over and then can also install/remove packages on demand).
But easiest way is just to copy over the iso content, minus the Calamares stuff. In this regard Whonix-Host iso should be as close to the fial Whonix Host installed version as possible.

I am not sure, but Whonix-Host needs it anyway otherwise it is rather pointless.

[1] Copying over files, pretty likely, yes. The Whonix host (or any VM) raw image doesn’t contain any installable packages before being converted to iso. Only already installed packages. Apt cache (debs) is cleared during the build process to save space. I doubt calamares somehow reconstructs debs from installed packages.

Makes sense.

I see requirement for internet by an installer as a disadvantage. User might have to enter wifi credentials twice. It adds more fragility, complexity. Think Tor, VPN, onion repos, connection slowness, data quota, and whatnot.

Debian installer is even worse. Often network cards or wifi adapters requiring nonfree drivers aren’t on the iso. These are only available online. After enabling nonfree repository. And Debian repository is unreachable due to no internet. I’ve seen many users fail at this requirement and use Ubuntu instead.

I guess since calamares copies over iso contents to disk it won’t be needing networking. That’s awesome since lower complexity and saves time.

Correct.

Custom user names would be unsupported. Username “user” is “the ideal user name”. It should be shared among all users of anonymity distributions. The rationale of this is explained here:

GitHub - Kicksecure/dist-base-files: base files for distributions - several important miscellaneous files, such as /etc/hostname, /etc/hosts, /var/lib/dbus/machine-id and more

I also see this as an advantage of usability. The less questions installers ask, the easier to use.

User user.

anon-base-files postinst script (anon-base-files.postinst) runs all steps required for user creation during installation of anon-base-files such as adduser, addgroup, pam-auth-update, passwd --lock root.

Now that I understand calamares a bit better as per [1], anon-base-files postinst script would only run during the build process when installed. It currently isn’t re-run during calamares installation - because calamares copies files - we didn’t configure it yet to doesn’t install packages.

The refined plan:

  • skip copying files from live iso /home/user folder to installed system
    • if that is not possible use a script to remove any unwanted files either during calamares [preferred] or during first boot
  • skip calamares user creation question
    • keep user user as it was already created by anon-base-files during raw image creation build process

Btw why would it be bad if files created in /home/user during live iso use would leak into the installed system? Because live contents should never leak to the disk? Well, that would make sense.

Can you find which calamares module is responsible for copying over the files? Then we might be able to find out how it can be configured and if /home/user can be excluded.


Calamares allows to run scripts indeed as per calamares/src/modules/shellprocess/shellprocess.conf at calamares ¡ calamares/calamares ¡ GitHub

I just did a test, and YES Calamares works without networking.
But the way I see it, the Whonix-Host ISO is also supposed to work as a standalone live solution, with virt-manager and Whonix-VM pre-installed. This is why I mean when I say that without networking the whole experience is pretty useless.

I get your idea. No user creation during install, user user is the default expected user on the installed OS.

But then why would you want to skip copying files from live iso /home/user? It could as well stay that way IMHO. User user is expected to have a modern Desktop environment with a couple of folders being there. I don’t see the problem.

You just need to remove the lines - users in /etc/calamares/settings.conf

I just build a Whonix-Host 15.0.0.9.4. All good:
Installs without networking → OK
Installs without user creation → OK
Boots into newly installed system with user user → OK

Things to be done now:
*Modify /etc/calamares/settings.conf
*Remove live-config from /etc/calamares/modules/package.conf (no need to remove it, as it is already not in the ISO, breaks the install otherwise)
*Enable user user auto-login

Things yet to be fixed/decided
*The Whonix VMs still do not boot in the live iso (not in read-only mode)
*When booted in persistent mode (=on the installed version), they should be reverted back to read-write mode, otherwise it won’t work.
*Branding…

1 Like

See pull requests: Pull requests ¡ Kicksecure/libvirt-dist ¡ GitHub

1 Like

Yes. Whonix Host is should have functional network. For sure. But calamares not requiring networking is awesome too.

I thought that’s also your suggestion.
Rationale being, activities done in Live (iso) mode shouldn’t end up on hard drive?

Yes. Files from /etc/skel. Not a contradiction to above. /home/user should be similar to Whonix-Workstation after first boot from hard drive.

Very good. Merged. But not tested yet.

These modules in https://github.com/Whonix/whonix-libvirt/blob/master/etc/calamares/settings.conf… Full quote:

- exec:
  - partition
  - mount
  - unpackfs
  - sources-media
  - machineid
  - fstab
  - locale
  - keyboard
  - localecfg
  - networkcfg
  - hwclock
  - services-systemd
  - bootloader-config
  - grubcfg
  - bootloader
  - packages
  - luksbootkeyfile
  - plymouthcfg
  - initramfscfg
  - initramfs
  - sources-media-unmount
  - sources-final
  - umount

We need to understand these modules at least on a high level.

sources-media

/usr/lib/calamares/modules/sources-media/module.desc executes /usr/sbin/sources-media. Was looking at it. Dunno what it is needed for. Something with sources list. Likely not needed because this is already done in Whonix host raw image / package anon-apt-sources-list.

Generally, we need to know what the installer does so it doesn’t do anything we don’t want it to do.

Therefore this module is a candidate for disabling.

machineid

We want shared machineid by anon-base-files. We don’t want random machineid. (Discussed in forums / documented in anon-base-files.)

calamares/src/modules/machineid/machineid.conf at calamares ¡ calamares/calamares ¡ GitHub

“Whether to create an entropy file” sounds interesting but calamares upstream defaults are entropy: false and entropy-copy: false and package calamares-settings-debian /etc/calamares/modules/machineid.conf isn’t using that either so perhaps better not using module machineid for now.

locale

About timezone. We have package timezone-utc. Hence, this module is probably better disabled.

localecfg

locale should already be correctly set during build process. Hence, this module is probably better disabled.

networkcfg

Not sure. Might be better set by GitHub - Kicksecure/kicksecure-network-conf / Kicksecure Network Configuration

hwclock

Dunno yet if needed.

services-systemd

not needed as per calamares/src/modules/services-systemd/services-systemd.conf at calamares ¡ calamares/calamares ¡ GitHub since does nothing by default and because such things would be configured through Whonix packages.

Generally, I am much more eager to have Whonix packages configure anything. That way it is easier to understand and later on easier to change through upgrades.

bootloader-config

A calamares-settings-debian thing, not calamares upstream thing.

/usr/lib/calamares/modules/bootloader-config/module.desc calls /usr/sbin/bootloader-config

Looks useful.

if [ -d /sys/firmware/efi/efivars ]; then
    echo " * Installing grub-efi (uefi)..."
    DEBIAN_FRONTEND=noninteractive chroot $CHROOT apt-get -y install grub-efi-amd64 cryptsetup keyutils
else
    echo " * install grub... (bios)"
    DEBIAN_FRONTEND=noninteractive chroot $CHROOT apt-get -y install grub-pc cryptsetup keyutils
fi

Though, I wonder if that requires networking. Otherwise we could perhaps cache these packages + dependencies somehow so it would work without internet connection too?

grubcfg

Probably required since it modifies /etc/default/grub depending on configuration (using full disk encryption or not).

bootloader

Probably required.

luksbootkeyfile

Dunno yet.

plymouthcfg

We probably don’t want plymouth. Extra complexity. Experienced some bugs in past. Using it on none of my systems. Whnix VMs also don’t have plymouth.

initramfscfg

Probably required.

initramfs

Probably required.

sources-media-unmount

Similar to sources-media.

sources-final

Similar to sources-media.

I did a try after removing all the modules you suggest to disable. It seems some of them were still ran nonetheless…
I’ll try a more thorough process tomorrow.

Would that mean no possibility for the user to choose his location and timezone during install?

1 Like

Yes. No possibility.