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

Whonix host operating system

Two solutions I see here:

  1. Using Device Mapper snapshotting which operates on the block/sector level as opposed to the file level of stackable (live) filesystems:
  1. Using compression on live data somehow
2 Likes

Since it is a live system you don’t need to modify them.
Overlayfs will copy each file which is opened for writing (like booting the VM images, changing permissions) to RAM.
During building you need to set the VM disk to ro, set the right permissions and then use grub-live in the VMs themselves.
If you do that the system should work with roughly the same amount of RAM as a normal host OS + Whonix VMs.
You can copy the whole filesystem to RAM with the “toram” option and then remove the device you booted from.

3 Likes

To add to the conversation we were having about GNOME vs. XFCE in Whonix host OS:

For those who use VeraCrypt to encrypt their Whonix VMs, I’ve heard that native VeraCrypt unlocking support will eventually show up in GNOME itself, due to the work Tails did to add it in their code to GNOME.

That would add a +1 for me (and others who use VC volumes) for GNOME in host. Its volume unlocking (vs. VeraCrypt’s official binary) is also incredibly faster due to using kernel driver vs. VC app which uses user space driver.

Thanks for the link, I will read it over the weekend!

Very good idea, I’ll try that right away! :+1:

2 Likes

@Algernon

Didn’t work.
What I did:

(on the host hardened machine)

chmod 444 /var/lib/libvirt/images/*.qcow2
chown libvirt-qemu:libvirt-qemu  /var/lib/libvirt/images/*.qcow2

Still copies the file into RAM, before failing with Block node is read-only error:

Error starting domain: internal error: qemu unexpectedly closed the monitor: 2019-05-03T10:07:05.043772Z qemu-system-x86_64: -drive file=/var/lib/libvirt/images/Whonix-Workstation.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: Block node is read-only

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1400, in startup
    self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-05-03T10:07:05.043772Z qemu-system-x86_64: -drive file=/var/lib/libvirt/images/Whonix-Workstation.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: Block node is read-only
1 Like

When did you run those commands? While running the iso i.e. live-mode or on the OS in persistent mode?

Edit: You also need to set the VM images to ro in virt-manager (can be also done when in live mode)

Also maybe check if the permissions are still correct on the final iso / squashfs filesystem. Just figured out that when running a VM the permissions of the VM images change to libvirt-qemu:libvirt-qemu, but when the VM stops they fall back to root:root .

1 Like

I ran these commands in the raw image before the ISO conversion.

Didn’t know this option was available, do you mean like this?

OK I’ll do everything again and try it out.

1 Like

I rebuilt everything from the beginning and made different tries, some good news to report.

First, @Algernon your solution did the trick! It works now in live mode with ro permissions + ro in virt-manager! The files are not copied anymore in RAM :+1:

Would you know how to enable this option automatically in the .xml files?

So to sum up, now I have a bootable UEFI/BIOS ISO file based on Hardened Debian with Calamares, virt-manager Whonix-Gateway and Whonix-Workstation, all working! :grinning:

I did test the install successfully on an external USB disk and a standard SATA HDD. Both BIOS/UEFI mode, full-disk encryption.

Just a few things that remain to be ironed out/thought of:

  • Debian Live user has passwordless sudo rights by default. Very bad. Root password is still ‘changeme’. An ideal solution would be to give the option to enable admin rights before landing on the desktop (like Tails). In the meantime, I am sure we can remove the passwordless sudo rights in some config file somewhere, just didn’t find out how yet.

  • I ran into a lot of problems with time settings. I don’t know how it is done on the Hardened Debian, but default UTC would never update to the right time, and as a result the Gateway was unable to connect to Tor (stuck at 25%). Even when adjusting by hand on both the host and the VM I was unable to connect to Tor.

  • The ro permissions of the Whonix VM are copied into the target. It would be better if during the install they would be set to normal 755. Don’t know how to do that.

  • The Calamares installer needs to be “Whonixified” (branding), now it looks like stuck Debian 10 installer

  • +Probably many other little things that I don’t remember of…

I will post on GitHub later today the complete scripts I used + a complete list of all the additional packages I have installed on the Debian Host.

2 Likes

Amazing!

onion_knight via Whonix Forum:

I am sure we can remove the passwordless sudo rights in some config file somewhere, just didn’t find out how yet.

Likely some file in /etc/sudoers.d folder.

Possibly looking similar/same as this:

user ALL=(ALL) NOPASSWD: ALL

You are probably right:

user@host:~$ sudo cat /etc/sudoers.d/live 
user ALL=(ALL) NOPASSWD: ALL

It is still not clear to me what exact files/settings take care of the default Debian Live User environment and variables: live-boot packages? live-config (my guess)? Need to sort it out somehow.

OK, I have uploaded the scripts on GitHub:

Warning: they are merely raw bash scripts, basically chrooting into the Hardened VM and taking care of the necessary stuff in the simplest way. They are certainly not production-ready and must be integrated into the Whonix build scripts by an experienced developer. I am not capable of that yet.

Also uploaded a list of all the additional software installed in the Whonix-Desktop Installer ISO:

@Patrick Regarding copyright: is it necessary? After all, it is just some bash commands and external programs with specific options… If yes, do you have an example of what should be indicated? Thanks.

1 Like

onion_knight via Whonix Forum:

It is still not clear to me what exact files/settings take care of the default Debian Live User environment and variables: live-boot packages? live-config (my guess)? Need to sort it out somehow.

Running apt-file list live-config might help understanding what the package does.

Also uploaded a list of all the additional software installed in the Whonix-Desktop Installer ISO:

https://github.com/onions-knight/whonix-stuff/blob/master/Whonix-Desktop%20list%20of%20new%20packages

That’s a bit much for listening in anon-meta-packages. That doesn’t mean it’s too much in an actually build iso. We’ll list only packages that we want and then their dependencies are implicitly added by those. I’ll see what I can do.

@Patrick Regarding copyright: is it necessary? After all, it is just some bash commands and external programs with specific options… If yes, do you have an example of what should be indicated? Thanks.
Better to have it consistently.

Most files in Whonix source code should have it, all bash scripts should have it. Here is an example: https://github.com/Whonix/Whonix/blob/master/whonix_build

Please review/merge:

OK, merged.

Regarding branding, actually very easy, all files live in /etc/calamares/branding/debian/ (with package calamares-settings-debian installed).

Just need to modify the .png files and the config file accordingly: /etc/calamares/branding/debian/branding.desc

1 Like
user@host:/etc/calamares/branding/debian$ sudo apt-file list live-config
sudo: unable to resolve host host: Name or service not known
live-config: /bin/live-config             
live-config: /bin/live-config-update
live-config: /lib/live/config/0010-debconf
live-config: /lib/live/config/0020-hostname
live-config: /lib/live/config/0030-live-debconfig_passwd
live-config: /lib/live/config/0030-user-setup
live-config: /lib/live/config/0040-sudo
live-config: /lib/live/config/0050-locales
live-config: /lib/live/config/0070-tzdata
live-config: /lib/live/config/0080-gdm3
live-config: /lib/live/config/0085-sddm
live-config: /lib/live/config/0090-kdm
live-config: /lib/live/config/0100-lightdm
live-config: /lib/live/config/0110-lxdm
live-config: /lib/live/config/0120-nodm
live-config: /lib/live/config/0130-slim
live-config: /lib/live/config/0140-xinit
live-config: /lib/live/config/0150-keyboard-configuration
live-config: /lib/live/config/1020-gnome-panel-data
live-config: /lib/live/config/1030-gnome-power-manager
live-config: /lib/live/config/1040-gnome-screensaver
live-config: /lib/live/config/1050-kaboom
live-config: /lib/live/config/1060-kde-services
live-config: /lib/live/config/1080-policykit
live-config: /lib/live/config/1090-ssl-cert
live-config: /lib/live/config/1110-anacron
live-config: /lib/live/config/1120-util-linux
live-config: /lib/live/config/1130-login
live-config: /lib/live/config/1140-xserver-xorg
live-config: /lib/live/config/1160-openssh-server
live-config: /lib/live/config/1170-xfce4-panel
live-config: /lib/live/config/1180-xscreensaver
live-config: /lib/live/config/1190-broadcom-sta
live-config: /lib/live/config/9990-hooks
live-config: /lib/live/init-config.sh
live-config: /lib/live/setup-network.sh
live-config: /usr/share/bug/live-config/presubj
live-config: /usr/share/doc/live-config/changelog.gz
live-config: /usr/share/doc/live-config/copyright
live-config: /usr/share/live/config/VERSION
live-config: /usr/share/live/config/xserver-xorg/nvidia.conf
live-config: /usr/share/live/config/xserver-xorg/vboxvideo.conf
1 Like

Please have a look:

If you like, please open a lot / most of these files in a text editor. Might give clues what these are doing.

We now have the initial packages and can add more dependencies as required.

  • whonix-host-xfce-kvm-freedom
  • whonix-host-xfce-kvm-nonfreedom

Most dependencies (such as live-config perhaps etc) should be added to whonix-host-xfce-kvm-freedom. This is because whonix-host-xfce-kvm-nonfreedom has Depends: on whonix-host-xfce-kvm-freedom.

1 Like

Ah, I did not see https://github.com/onions-knight/whonix-stuff/blob/master/2900_configure_desktop_sketch#L42-L52 earlier. This will help me with dependencies.

You would need to add something like:

<source file='/var/lib/libvirt/images/VM.img'/>
  <target dev='vda' bus='virtio'/>
  <readonly/>

to the xml file.
But as you said it needs to be changed to readwrite afterwards when using the installed host OS.
iirc just using the correct settings for the xml file should be sufficient i.e. you maybe don’t need to change the permissions of the file.
In this case one could maybe come up with some script which checks if we boot from an iso and accordingly sets the read only tag.
Another way would maybe be using virt-install instead of importing the VMs via the xml.

3 Likes