Whonix host operating system

onion_knight · March 16, 2020, 3:54pm

I don’t know. 440 should also work.

Great!

Great! Will try a new build now.

onion_knight · March 16, 2020, 5:01pm

Whonix-Host ISO 15.0.1.0.1-11 build breaks for odd reason. Safe to ignore and continue?

 #####################################################################
## INFO: BEGIN: usability-misc postinst configure' '
#####################################################################
'
+ case "$1" in
+ true 'INFO: Configuring usability-misc...'
+ adduser --no-create-home --home /nonexistent --quiet --system --group --shell /bin/false tunnel
+ true 'INFO: End configuring usability-misc.'
+ bisq_desktop_directories_workaround
+ '[' -f /var/lib/usability-misc/do_once/bisq_desktop_directories_workaround_version_1 ']'
+ mkdir -p /usr/share/desktop-directories
+ touch /var/lib/usability-misc/do_once/bisq_desktop_directories_workaround_version_1
touch: cannot touch '/var/lib/usability-misc/do_once/bisq_desktop_directories_workaround_version_1': No such file or directory
++ errorhandlergeneral
++ last_failed_exit_code=1
++ last_failed_bash_command='touch "/var/lib/usability-misc/do_once/${FUNCNAME}_version_1"'
++ output_cmd_set
++ '[' -o xtrace ']'
++ output_cmd=true
++ true 'INFO: Middle of function errorhandlergeneral of /var/lib/dpkg/info/usability-misc.postinst.'

Patrick · March 16, 2020, 6:28pm

Safe to ignore and should be fixed in 15.0.1.0.2-developers-only.

onion_knight · March 16, 2020, 8:27pm

Ok. Build 15.0.1.01-11 successful (ignoring this error).
Everything seems fine.

To sum up, what needs to be done in my opinion:

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)

Anything else?

Patrick · March 17, 2020, 11:19am

Whonix-Host · Workboard and live-mode · Workboard could use some triage. Tasks required for first public release could be tagged Whonix_15 vs tasks for future work could be left as is.

Which tasks would you consider release blockers?

I guess for example at minimum we should have a basic host firewall. → ⚓ T942 Whonix Host Firewall for Whonix Host

Patrick · March 17, 2020, 12:05pm

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

Then what about hdd live mode boot? Does this issue apply there too?
This implementation path might not work for installed disk live mode boot?
I don’t know. Not implemented yet. Currently installed (persistent) Whonix-Host does not have live-boot option.

Should be easy.

sudo apt install grub-live

If that works, could be added to anon-meta-packages.

onion_knight · March 17, 2020, 12:06pm

Personally I don’t see any blocker in the two lists.

This may however be a problem (not a blocker to me anyway) if swap is really a concern to you, as Calamares installer creates a swap partition by default:
https://phabricator.whonix.org/T904

Solutions:

Don’t care (the installation should be on a encrypted disk anyway, swap is encrypted too)
See how we can change Calamares settings so as to not provide a swap partition by default during partition

Regarding host firewall, I have no experience in that. So I am afraid I won’t be able to help much with that.

This being said, a lot of bugs/desired features will probably appear when we can test Whonix-Host (both live and persistent installation) more thoroughly.

Maybe already consider a first “alpha” build based on what we have (still pending last desktop configuration changes) that multiple people could test and report back?

onion_knight · March 17, 2020, 12:13pm

EDIT:
I forgot this one
https://phabricator.whonix.org/T914
Maybe not a blocker, but should definitely be taken care of, as it is inconvenient (as currently needs editing on first boot after Whonix-Host persistent installation in order to make it work).

Patrick · March 17, 2020, 12:23pm

Yes, ideally there would be a swap file but it’s not super critical as its encrypted swap partition.

Yes, that’s it for now since calamares does not support swap file support yet.

Not sure that is a good idea. For users with 4 GB RAM and more that might be OK but with less I don’t know if we should care and/or if swap would help.

Patrick · March 18, 2020, 2:36pm

4 posts were split to a new topic: Whonix-Host Firewall

onion_knight · March 18, 2020, 10:17am

Currently building 15.0.1.0.2-developers-only from scratch, to see how it goes.

Patrick · March 18, 2020, 1:19pm

Patrick · March 18, 2020, 2:54pm

Patrick · March 21, 2020, 10:47am

This is a search for project whonix-host, whonix-15 with status open.

https://phabricator.whonix.org/maniphest/query/_Obk7yld9FTN/#R

These tasks I think we should get done before the first release aka Whonix-Host release blocker.

All open Whonix-Host tasks (also lower priority, non-blockers):

https://phabricator.whonix.org/maniphest/query/tJZ0eiJ0CrLl/#R

onion_knight · March 22, 2020, 5:05pm

Great, I can take
https://phabricator.whonix.org/T910
https://phabricator.whonix.org/T969
I’ll first start with a new build, see if everything works fine, and test it further.

onion_knight · March 25, 2020, 11:39am

Whonix-Host-15.0.1.0.7-developers-only: field report

I build a new Whonix-Host 15.0.1.0.7, as well as Whonix-Gateway and Whonix-Workstation VMs and tested it out on real hardware. Not an extensive test, just to see if everything works as expected.

First of all, there is one thing important to consider during Whonix-Host build. If gw and ws VMs are not compressed first, the Calamares installation will take hours, and likely fail if not installing on a disk with less than 250 GB capacity. This is because Calamares installer seems to “think” that Whonix VMs really use 100 GB of space each. Compressing the gw and ws disk images BEFORE building Whonix-Host using qemu-img convert solves the problem:

qemu-img convert -f qcow2 -O qcow2

This is just an observation for builders, it is done manually at this stage, but could be added in the whonix-host build process.

Results:

Whonix-Host ISO/Calamares

Consider changing /etc/motd: “Whonix GNU/Linux” → “Whonix-Host GNU/Linux”
BIOS installation works fine. Installed and tested on real hardware. → great!
EFI installation is broken. The installation cannot proceed (more on this later).
EFI ISO doesn’t use the current kernel flags, see my pull requests (also replaced “Whonix Desktop” by “Whonix-Host” in both grub.cfg and isolinux.cfg files):
https://github.com/Whonix/Whonix/pull/432
https://github.com/Whonix/Whonix/pull/433
Whonix-Host currently does not have ntfs filesystem support. Quite annoying. I suggest adding ntfs-3g package. Maybe also consider adding dosfstools package. Both packages are very lightweight. (“dosfstools consists of the programs mkfs.fat, fsck.fat and fatlabel to create, check and label file systems of the FAT family.” GitHub - dosfstools/dosfstools: dosfstools consists of the programs mkfs.fat, fsck.fat and fatlabel to create, check and label file systems of the FAT family.)
Some functionalities to fully support desktop integration of mounting encrypted and non-encrypted disks appear to be missing: this means encrypted partitions must be decrypted and mounted manually (likely related to some polkit configuration nightmare…).

Whonix gw/ws VMs integration

Whonix-VM resolution size is fixed (automatic 1920x1080 on first boot) → great!
Whonix-VMs desktop background colors are currently wrong (inverted: gw uses ws color and ws uses gw color). Couldn’t do a pull request as I don’t remember what files take care of this

Whonix-Host installed version

Installed Whonix-Host GRUB menuentry is currently “Whonix GNU/Linux” → shouldn’t it be changed to “Whonix-Host GNU/Linux”? Same thing for /etc/motd
persistent-mode-to-read-write half works: after installation, Whonix VMs are correctly set to -disk readonly=off but their file permissions are still read-only (0440). They will fail to boot in virt-manager (Error starting domain: internal error: process exited while connecting to monitor: 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)
nfts filesystem, mounting disks in thunar: see above

In general, what further tests would you suggest me to perform on an installed Whonix-Host system?

Patrick · March 25, 2020, 12:17pm

Awesome!

Packages: yes, please add here anon-meta-packages/control at master · Whonix/anon-meta-packages · GitHub

Strange.

Don’t we create a sparse qcow2 image here? //cc @HulaHoop

https://github.com/Whonix/Whonix/blob/master/build-steps.d/2400_convert-raw-to-qcow2#L37

And then don’t we copy the sparse qcow2 image as sparse qcow2 image into the Whonix-Host raw image?

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

Anything that needs to be fixed to make it sparse indeed?

-f filename
-O output format

Possible to use long instead of short qemu-img command line parameters?

We convert qcow2 to qcow2? At what point that command says “use compression”?

Does that mean we have to settle for compressed qcow2 images for Whonix-Host ISO and Whonix-Host installed? Performance degradation? Unpack on installed Whonix-Host?

Yeah. There’s /etc/motd.d and /etc/issue.d nowadays. I’d like to port to that.

Hopefully fixed when working on these:

Need to make special note to test Whonix-Host too.

I thought the blue color is most friendly, pretty and workstation the place to spend most time. Therefore added there.

Should be doable. That, /etc/issue, /etc/motd could use a ticket.

Please add comment to the ticket.

I guess ⚓ T910 anti-forensics / amnesia testing of Whonix-Host in Live mode is the only major test for now that comes to mind that you’re already aware off. Everything else you seem to have covered already.

onion_knight · March 25, 2020, 12:41pm

It’s just an empiric finding. The term “compress” is probably not appropriate. When using qemu-img convert command, the .qcow2 size seems to match its real size, not its virtual potential one:

user@host:~$ sudo ls -lh /var/lib/libvirt/images/
total 5.3G
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 2.5G Mar 24 14:34 Whonix-Gateway.qcow2
-r--r----- 1 root         root         2.9G Mar 24 14:34 Whonix-Workstation.qcow2

(instead of 100G before qemu-img).

I didn’t notice any performance degradation. Once again, “compress” is probably not the right term.

Full command:

qemu-img convert -f qcow2 -O qcow2 /path_to_whonix_vms/whonix_vms.qcow2 /path_to_whonix_binary/whonix_vms.qcow2

I guess we could probably replace the cp --sparse=always command by qemu-img convert. In my experience, the result is the same, only .qcow2 images “advert” their real size when using qemu-img convert.

OK!

OK, so not an issue. Although I prefer it the other way personnally

OK

Ok, will test later

I’ll try to find out what’s happening with this EFI installation failure. More details on that later.

HulaHoop · March 25, 2020, 3:08pm

Yes

Maybe the problem onion_knight ran into was caused by incorrect order of operations?

Yes

Seems redundant. qcow2 does the optimal compression by default IIRC. I will read more.

EDIT:

We already do the best we can in the compression department.

Of course the degree of compression you get depends on the amount of zeroed free space in the image, and the amount by which qcow2 is able to compress the other blocks containing data.

qcow2 uses zlib for compression, so the compression won’t be that spectacular. It’s better to keep the filesystems “sparse” in the first place, by ensuring unused disk blocks are zeroed.

For ext2/3 filesystems, Fedora ships a utility called zerofree, which you can either run inside the guest, or run offline from guestfish. This turns unused filesystem blocks into zeroes, which will make outside compression eg with qcow2 much more efficient. For other filesystems, the usual trick is to create a large file of all zeroes until you fill up the free space, then delete it.

onion_knight · March 25, 2020, 6:51pm

As I said I don’t think it’s a compression issue, I think it is related to how Calamares “perceives” the gw/ws VM size when it rsync the ISO squashfs filesystem into the install target. When copying .qcow2 files created by cp --sparse it interprets their virtual 101G size as a real size, whereas when copying .qcow2 files obtained with qemu-img convert, it sticks to their actual size.