Whonix-Host Operating System (OS) ISO

[onion_knight]

Great. building 15.0.0.9.5-developers-only now.

@Patrick

https://github.com/Whonix/whonix-libvirt/blob/master/etc/calamares/modules/users.conf.whonix

• calamares/src/modules/users/users.conf at calamares · calamares/calamares · GitHub
• Could you try please setRootPassword: false ? We don’t want to ask for or set a root password. That is because root account is locked by Whonix default. (Details: Strong Linux User Account Isolation)

OK, I’ll try that. I can foresee problems with Calamares installer that needs root password access. We’ll figure that later.

@Patrick

Re roadmap… Actually there is. We used to keep good track of open tasks:

• Whonix-Host · Workboard
• live-mode · Workboard

Do you get (e-mail) notifications from Whonix phabricator? Some discussions would be good to have there.

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

Please see: ⚓ T914 Whonix Host Live - enable KVM readonly mode - virt-xml vm-name --edit --disk readonly=on

Yes, I receive e-mail notifications. I’ll have a look.

[onion_knight]

@Patrick

https://github.com/Whonix/whonix-libvirt/blob/master/etc/calamares/modules/users.conf.whonix

• calamares/src/modules/users/users.conf at calamares · calamares/calamares · GitHub
• Could you try please setRootPassword: false ? We don’t want to ask for or set a root password. That is because root account is locked by Whonix default. (Details: Strong Linux User Account Isolation)

Actually, we don’t use this file anymore in our current Calamares install sequence (module users is skipped), thus I guess no need to change it.

Currently when booting 15.0.0.9.5 Whonix-Host iso (and all previous recent successful builds), user user has full sudo rights (although not in sudo group). This behavior is then reproduced in the Whonix-Host installed version. I gather this not the expected behavior as per current “restricted root” policy? What should be the default expected behavior regarding sudo/root/admin rights in Kicksecure/Whonix GW-WS?

Regarding last merged pull requests (branding), everything seems to work as intended (see screenshots below).

Still needs fixing/considering

• Whonix VM disk images are still not set in ro mode
• We should have auto-login enabled for user user (unpractical to log in when booting an ISO file)
• We need to replace Kicksecure references by Whonix-Host everywhere (I am thinking /etc/motd, grub, anything else?).
• Test on real hardware (both EFI/BIOS)…
• Get rid of the default XFCE4 desktop image (replace with simple color?), add some Desktop icons (cosmetic changes, not urgent)

Some screenshots:

1. Booting on Whonix-Host Live ISO 15.0.0.9.5, showing desktop, Install Whonix-Host icon, as well as a terminal displaying user user root access
   

   

2. Clicking on Install Whonix-Host icon launches Calamares. It needs sudo rights to proceed.
   

   

3. Whonix-Host Installer (Calamares) Welcome page
   

   

4. Whonix-Host Installer (Calamares), installing in progress (full-disk encryption)
   

   

[Patrick]

Excellent!

@onion_knight

Actually, we don’t use this file anymore in our current Calamares install sequence (module users is skipped), thus I guess no need to change it.

Alright. Let’s change that anyhow please to avoid confusion and maybe just in case?

@onion_knight

Currently when booting 15.0.0.9.5 Whonix-Host iso (and all previous recent successful builds), user user has full sudo rights

This is expected. To elaborate, when user user runs “sudo something” the user should be prompted for the password. If the password is correct, the command would run as root.

This might change in future when multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode is implemented.

@onion_knight

(although not in sudo group)

Your screenshot shows that running id that user user is a member of group sudo. This is expected as of now. Same as in Whonix VMs.

@onion_knight

I gather this not the expected behavior as per current “restricted root” policy?

Untrusted Root - improve Security by Restricting Root is a development goal but not yet implemented.

@onion_knight

What should be the default expected behavior regarding sudo/root/admin rights in Kicksecure/Whonix GW-WS?

Whonix (or Kicksecure) Host for now same as 15.0.0.9.4 gw/ws VMs.

@onion_knight

Regarding last merged pull requests (branding), everything seems to work as intended (see screenshots below).

Awesome!

@onion_knight

Whonix VM disk images are still not set in ro mode

https://phabricator.whonix.org/T914#18825

@onion_knight

We should have auto-login enabled for user user (unpractical to log in when booting an ISO file)

Makes me wonder if whonix-libvirt is the correct place to implement Whonix calamares settings.

whonix-libvirt.hide currently hides /etc/lightdm/lightdm.conf.d/whonix-autologin.conf. Therefore disables autologin.

• Whonix-Host installed should not have autologin. That’s why above line.
• Whonix-Host iso should have autologin.

These are somewhat conflicting goals. Debian solves that by uninstalling package calamares-settings-debian at the end of calamares. We can’t do that because whonix-libvirt does other things which still need to be done in Whonix-Host installed.

Solution 1) Have a systemd unit file that detects being run from iso that creates the required file to auto login.

Solution 2) a separate package calamares-settings-whonix which is only installed on Whonix-Host iso but not in Whonix-Host installed.

What do you think?

@onion_knight

We need to replace Kicksecure references by Whonix-Host everywhere (I am thinking /etc/motd, grub, anything else?).

There’s a package whonix-base-files for that already. That’s likely missing in Whonix-Host.

That’s because Whonix-Host does not depend yet on whonix-shared-packages-dependencies-cli

whonix-shared-packages-dependencies-cli:

• Pre-Depends: whonix-legacy
• Depends: whonix-base-files, anon-apt-sources-list, whonix-firewall, whonixsetup,

That’s because:

• whonix-firewall isn’t tested on Whonix-Host yet. → ⚓ T942 Whonix Host Firewall for Whonix Host
• whonixsetup isn’t tested with Whonix-Host yet. (Should be same as workstation.)

Fixed in git master just now:

add whonix-base-files to whonix-host-xfce-kvm-freedom

@onion_knight

Get rid of the default XFCE4 desktop image (replace with simple color?), add some Desktop icons (cosmetic changes, not urgent)

Yes:

• ⚓ T929 Whonix XFCE Wallpaper / Background Image
• Whonix XFCE Wallpaper / Background Image

[onion_knight]

@Patrick

Alright. Let’s change that anyhow please to avoid confusion and maybe just in case?

Ok, done, but untested.

Update users.conf.whonix

@Patrick

This is expected. To elaborate, when user user runs “sudo something” the user should be prompted for the password. If the password is correct, the command would run as root.

@Patrick

Untrusted Root - improve Security by Restricting Root is a development goal but not yet implemented.

@Patrick

Whonix (or Kicksecure) Host for now same as 15.0.0.9.4 gw/ws VMs.

Ok, so nothing wrong and nothing to do. Great

@Patrick

Your screenshot shows that running id that user user is a member of group sudo . This is expected as of now. Same as in Whonix VMs.

Yes, you are right. Oversight from me. Cool.

@onion_knight

Whonix VM disk images are still not set in ro mode

https://phabricator.whonix.org/T914#18825

OK, let me investigate this. I’ll follow your instructions.

@Patrick

Makes me wonder if whonix-libvirt is the correct place to implement Whonix calamares settings.

whonix-libvirt.hide currently hides /etc/lightdm/lightdm.conf.d/whonix-autologin.conf . Therefore disables autologin.

• Whonix-Host installed should not have autologin. That’s why above line.
• Whonix-Host iso should have autologin.

These are somewhat conflicting goals. Debian solves that by uninstalling package calamares-settings-debian at the end of calamares. We can’t do that because whonix-libvirt does other things which still need to be done in Whonix-Host installed.

Solution 1) Have a systemd unit file that detects being run from iso that creates the required file to auto login.

Solution 2) a separate package calamares-settings-whonix which is only installed on Whonix-Host iso but not in Whonix-Host installed.

What do you think?

I think that the best option would be probably to have our own package calamares-settings-whonix and put there only the Calamares config files that we need. BUT: I have no idea how hard and sustainable it is in terms of maintainability, etc. I couldn’t do it myself.

But anyway where did you see that calamares-settings-debian took care of auto-login? My understanding is that it was taken care of by live-config default settings, and broke when we removed that package. We could however add /etc/lightdm/lightdm.conf.d/whonix-autologin.conf in our hypothetical calamares-settings-whonix package which would be uninstalled at the end of calamares installer.

@Patrick

There’s a package whonix-base-files for that already. That’s likely missing in Whonix-Host.

That’s because Whonix-Host does not depend yet on whonix-shared-packages-dependencies-cli

whonix-shared-packages-dependencies-cli :

• Pre-Depends: whonix-legacy
• Depends: whonix-base-files, anon-apt-sources-list, whonix-firewall, whonixsetup,

That’s because:

• whonix-firewall isn’t tested on Whonix-Host yet. → ⚓ T942 Whonix Host Firewall for Whonix Host
• whonixsetup isn’t tested with Whonix-Host yet. (Should be same as workstation.)

Fixed in git master just now:

Great!

[Patrick_mobile]

Would you like to move calamares settings to its own git repository (authorship git history) or shall I do that?

@onion_knight

We could however add /etc/lightdm/lightdm.conf.d/whonix-autologin.conf in our hypothetical calamares-settings-whonix package which would be uninstalled at the end of calamares installer.

Yes. (Just filename needs to differ to avoid package conflict.)

[onion_knight]

@Patrick_mobile

Would you like to move calamares settings to its own git repository (authorship git history) or shall I do that?

Please do it

[Patrick]

Done: GitHub - Kicksecure/live-config-dist
(Used a more generic package name so this package can be used for both Whonix, Kicksecure, Calamares and anything else that should only be done when booting the ISO.)
Highlights:

• install live-config-dist during build process
• uninstall live-config-dist package by calamares at the end
• Whonix-Host ISO autologin
• Whonix-Host installed no-autologin
• allow running calamares without sudo password entry

Untested. Could you please have a look at the commit history?

[onion_knight]

Great!

@Patrick

Untested. Could you please have a look at the commit history?

Do you mean testing a new build with these commits?

[Patrick_mobile]

That would be good but not what I meant. If that’s possible without a new git tag yet.

I meant looking at list of commits here
Commits · Kicksecure/live-config-dist · GitHub
then clicking each and see if something looks wrong or just to stay up to date.

[onion_knight]

OK!
In the meantime I launched a new build 15.0.0.9.6

Breaks at 1700 install packages:

The following packages have unmet dependencies:
 whonix-host-xfce-kvm-nonfreedom : Depends: whonix-host-xfce-kvm-freedom but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

[Patrick]

There must be more apt errors earlier when trying to install whonix-host-xfce-kvm-freedom or earlier than that.

Looking into this now.

[Patrick]

That build issue was a bit tricky to identify and fix. whonix-base-files couldn’t be installed because it couldn’t replace kicksecure-base-files.

try fix kicksecure-base-files vs whonix-base-files package conflict

Provides: kicksecure-base-files

Build should be fixed in 15.0.1.0.0-developers-only.

Also thanks to travis.debian.net I might be finally able to set up a CI to detect such issues automated, faster in future.

[onion_knight]

Great! I will try to build it again. Regarding your commits history it seems fine to me, but I prefer to test a new iso build.

[onion_knight]

Build seems fine. I was tagged Whonix-Host-XFCE-15.0.1.0.0-3-ga2e3ae6bf4cf48b4a9277de39c9e538da1e186ff I don’t know why?
Juste a small fix for the installer desktop icon:

Update install-host.desktop

I will try to investigate this read-only bug with the VMs later.

[Patrick]

Nice!

@onion_knight

Update install-host.desktop

I deliberately removed as many mentions of hardcoded Whonix strings. Maybe we could re-name the file instead? The idea is that some Kicksecure package needs to modify only a minimal amount of files and voila, we have a Kicksecure installer too.

@onion_knight

I was tagged Whonix-Host-XFCE-15.0.1.0.0-3-ga2e3ae6bf4cf48b4a9277de39c9e538da1e186ff I don’t know why?

Most likely you build from git master in that case. If you git fetch/merge Whonix/Whonix then you’re a few commits ahead of the latest git tag. I deliberately added years ago the resulting files to contain the git commit in such cases to distinguish between builds from “real git tags” vs “something not git tagged”. Try running git describe in Whonix main source code folder. Similar to usual VM build instruction son how to checkout a specific tag and make sure it’s really used (git describe).

[onion_knight]

@Patrick

I deliberately removed as many mentions of hardcoded Whonix strings. Maybe we could re-name the file instead? The idea is that some Kicksecure package needs to modify only a minimal amount of files and voila, we have a Kicksecure installer too.

Yes, better then to rename live-config-dist/usr/share/pixmaps/install-whonix-host.png at master · Kicksecure/live-config-dist · GitHub to “install-host.png”.

[onion_knight]

Regarding read-only: see my comment here
https://phabricator.whonix.org/T914

[onion_knight]

While testing Whonix-Host-XFCE-15.0.1.0.0-3.iso I realized that it doesn’t have lvm support. Meaning it cannot manage encrypted disks with " LVM on LUKS" method. I strongly suggest adding package lvm2.

[Patrick]

https://github.com/Whonix/Whonix/blob/master/build-steps.d/1800_copy_vms_into_raw#L35

old:

   $CHROOT chmod -v -R 444 "/var/lib/libvirt/images/Whonix-Gateway.qcow2"
   $CHROOT chmod -v -R 444 "/var/lib/libvirt/images/Whonix-Workstation.qcow2"

chmod 444 meaning read allowed for owner, group, public.
(As per https://chmod-calculator.com/.)

Would chmod 440 (public cannot read the images) be better? In other words, why should all users on the system be able to read these images? Or is that the default?

I also find octal hard to work with. The following is much easier to understand:

• chmod u (user/owner)
• chmod g (group)
• chmod o (others)

Therefore changed from octal to symbolic:

   $CHROOT chmod --verbose --recursive ugo-r "/var/lib/libvirt/images/Whonix-Gateway.qcow2"
   $CHROOT chmod --verbose --recursive ugo-r "/var/lib/libvirt/images/Whonix-Workstation.qcow2"

This is related to fixing ⚓ T914 Whonix Host Live - enable KVM readonly mode - virt-xml vm-name --edit --disk readonly=on.

[Patrick]

@onion_knight

While testing Whonix-Host-XFCE-15.0.1.0.0-3.iso I realized that it doesn’t have lvm support. Meaning it cannot manage encrypted disks with " LVM on LUKS" method. I strongly suggest adding package lvm2 .

Done.

add lvm2 to kicksecure-cli