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

Whonix host operating system

There is already some discussion ongoing in the Whonix-Live mode thread but I guess a dedicated thread is more suitable.

What would you consider important for an (official) Whonix host OS?

Which OS should be used?
Similar to @Hexagon I would also suggest something debian based. Linux Mint is said to be the most user friendly for linux newbies but as far as I know the security track is not good.
However, Debian is usually not that up to date so it might not run on the latest and greatest hardware. Maybe using backports and tracking the vanilla kernel could help to some extend.
I think Fedora is more up to date but hence it also is more volatile and changes happen more often. Practically I don’t have much experiences with it.
There is already qubes-whonix and I would like to use Qubes but (in particular with the upcoming 4.0 version) hardware support will be even more of a problem.

UEFI and graphics drivers are the biggest issues I can think of and then maybe other drivers for ethernet, wifi … .
Tails and Knoppix work on most hardware I have so installing the same packages would probably solve most problems with drivers

Most stuff should happen in VMs.
For general usability maybe network manager and a browser for captive portals would be useful. This could maybe also be implemented in a VM; starts to look like Qubes then …

Full disk encryption should be mandatory. For this you either need an installer/tutorial or make an already encrypted image available with some setup utility where the user changes the master key and password, expands the image to fill the disk …

In general I think a hd image which is just transferred to an USB stick or normal hard drive would be the most useful. The advantage for the end user would be a rather easy setup (except maybe FDE) and using a host which does not spy on the user.
Disadvantages would be the need to download a likely big image, customization will be harder (not a disadvantage regarding anonymity), driver problems (but could be the same if you install manually), a higher workload for the devs.

1 Like

Yes. Tails does it somewhat like that?

Mixing with Fedora wouldn’t be my first choice. Because then users and developers have to know a little bit about both. (I am still hoping that Qubes will replace Fedora with Debian in dom0 eventually.)

That doesn’t mean I am against it. If someone is adamant about Whonix host operating system being based on Fedora, that’s better than nothing.

Qubes technically is a great host operating system. Specifically since it has superb Whonix support with Qubes-Whonix. Hardware support indeed is bad.

A Whonix host operating system would be somewhat reinventing Qubes. Maybe worth it due to hardware support. If it’s about hardware support, it would also be possible to port Qubes to VirtualBox or KVM or anything.

They specifically made this possible. Reference:
http://theinvisiblethings.blogspot.de/2013/03/introducing-qubes-odyssey-framework.html

Yes. Like in Qubes, where even upgrading the host (called dom0 in Qubes) is partially done inside a VM. (Qubes host/dom0 has no networking. Upgrades are fetched within the UpdateVM.)

Mandatory sounds a bit hard. Sounds like patronizing users, an anti feature. I’d like default full disk encryption more.

Not a deal breaker either way. When someone contributes something as big as this, of course lots of freedom of choice has to be granted.

There is cryptsetup reencrypt. So the image could be encrypted by default and the masterkey and password would have to be changed by the user by using cryptsetup reencrypt. (Not totally sure. Would require research to confirm.)

I agree :slight_smile:

Yes, I was also thinking about cryptsetup-reencrypt but still some setup utility would be required to make this user friendly. In some thread here there was already a tutorial for something similar which used VirtualBox on Windows so the user can still look up something in case of errors.
You could also do it like this:
Download the image + setup script . Download some iso which has cryptsetup-reencrypt installed (I’m not sure if debian live isos ship with it). Attach image + iso + usb dongle/hard drive to the VM and boot it from the iso. Run the script which invokes cryptsetup-reencrypt, transfers the image to the usb/hdd and resizes the partitions so they fill the entire hard drive.
Another option would be to use an unencrypted images and the setup utility just creates an encrypted filesystem.
Just trying to gather some ideas …

1 Like

Whonix Host may not be too far away. In theory.

We’re close to with “hardened debian” (new name still needed).

We already have a raw image creation during build process. Was asking myself, what’s so hard about (perhaps compressing and) uploading it? Once uploaded, users can write it onto an USB drive. (Perhaps using dd.)


Installation of Tails is also a multiple step process:
https://tails.boum.org/install/index.en.html

Burn image to USB:

(These tools might not work for Whonix since Whonix would produce a raw image rather than iso image. Dunno if that makes a difference for these tools.)


Disk size issues: We don’t know how big the target device is. A 16 GB stick (we only need perhaps 4 GB) or 1000 GB USB hard drive. We have --vmsize but what size do we select for default download users? I remember netrunner-odroid has a script “on boot, expand my parition to maximum size of this boot drive”.


Once “hardened debian” (new name still needed) is writeable to disks using that instructions it’s not far to install a virtualizer by default and to copy the VM images over and set them up by default. Just one more build step.


Limitations:


[1] Imagine one installed Debian using Debian installer without encryption. How could one encrypt the system with re-installation?


Disadvantages: Host operating system opens a can of worms. Hardware support to only mention one issue.

I actually have/had a half baked script which does this but got distracted …
It would build a host image through some host meta-package and copy the GW and WS into the image. The images were already encrypted and it asks in the initrd for a new password and reencrypted everything. It also grows the partition to fit the disk size.
Encrypting the images before compression is pointless and makes compression a bit harder …
But it should also be possible to supply unencrypted images which get encrypted afterwards.
Hardware and general host OS support is indeed a problem. The meta package also installed graphics drivers or nic firmware. My intention was to not have anything Whonix specific on the host i.e. it should be a normal Debian image and no Whonix specific packages should be installed so that only Debian stuff could possibly break on the host and hence “they” need to fix it^^ . I’m not sure if this is realistic though and users would still probably pop up in the Whonix forum in case something Debian-only breaks.

You could also make an image based on Debian testing with support for newer hardware but then security support would be worse.
I’m not sure if it is feasible to support a host OS for everyones hardware. If the stable or testing images work, good for you, if they don’t we can’t really help you except maybe for adding packages which are in Debian or directing the user to the Debian forums.

2 Likes

That’s ok. I’ve been told that

Debian is supposedly non-hostile, welcoming if derivatives redirect bug reports and support to Debian. That is, as long as the derivative is build using standard Debian build tools (which we do) and not recompiling packages (which we don’t do, we use the usual packages.debian.org) so “any bug applying to the derivative should equally apply to Debian”.

Debian supposedly doesn’t have a policy “not purely from us, go away”.

Even if we can’t provide the same level of user support quality it is ok.

users would still probably pop up in the Whonix forum in case something Debian-only breaks.

For sure but that is ok.

I guess Whonix build script could do that too (possible you were already using it).

Sounds good.

Awesome, I wonder how you implemented that.

It also grows the partition to fit the disk size.

Great!

Encrypting the images before compression is pointless and makes compression a bit harder …

Indeed.

The meta package also installed graphics drivers or nic firmware.

If it includes non-free dependencies, let’s have one free and one non-free variant.

My intention was to not have anything Whonix specific on the host i.e. it should be a normal Debian image and no Whonix specific packages should be installed so that only Debian stuff could possibly break on the host and hence “they” need to fix it^^ .

Sounds great. (I was considering something similar with debian-vm.) Whonix build script can support many flavors.

But even a hardened-debian-something-no-whonix may be worthwhile. And also a Whonix Host which comes with Whonix images already set up.

You could also make an image based on Debian testing with support for newer hardware but then security support would be worse.

Whonix many releases ago was Debian testing based. There’s a writeup in the wiki. In short: that was a nightmare. Yet, contributions welcome.

1 Like

https://www.whonix.org/wiki/Dev/Operating_System#Why_is_Whonix_.E2.84.A2_based_on_Debian_Stable.2C_not_Debian_Testing.3F

@onion_knight

This looks very useful.

1 Like

@All

Are there any features or things related to the general setup that you would like to see i.e. installed packages network setup (no network on the host, nat, macvtap ) I’d go for KVM as hypervisor + virt-manager.

2 Likes

created a task list (we don’t have to implement all for first iteration):

https://phabricator.whonix.org/tag/whonix-host/

Do you mean Qubes style non-networked host? Is that possible? How would updates work?

I was also thinking about a toririfed host but that makes things a lot more difficult. It’s just a pipe dream for now and no one might ever contribute this.

That’s cool, I wasn’t sure if KVM was going to happen. Please use a appendix -kvm for eventual meta packages since I might implement -virtualbox later on too.

On a second thought which was inspired by your post this is a good chance to revisit VirtualBox vs KVM on Debian / Linux hosts. -> Why use VirtualBox over KVM on Linux hosts? Considering deprecation of VirtualBox on Linux hosts.

Related:

A series of scripts for downloading, verifying, and installing KVM Whonix on Debian. - juxtin/install-whonix


This package could be very handy on a Whonix-KVM-Host… (You might know it - but I am also talking to wider public.)

It has all the Whonix KVM XML files:
https://github.com/Whonix/whonix-libvirt/tree/master/usr/share/whonix-libvirt/xml

I’ll post the working script I use tomorrow so you can have a better understanding and even test it if you like to do so.

2 Likes

incron for automating shared folder permissions on the fly?

BTW thanks for your enthusiasm and awesome contributions. You’ve made a lot of our visions for Whonix become a reality.

Maybe a selective outbound firewall to allow approved (Torrified applications in this case) access:

Here is the bash script I use.

Just tested it with latest Whonix 15 (after converting the .qcow2 file to a .raw file). Works fine, at least with BIOS mode. UEFI mode boots but does not reach graphical target with KVM, probably needs some more testing (I didn’t test the iso file with VirtualBox).

All the code comes originally from

https://willhaley.com/blog/custom-debian-live-environment/

I just put all together after trying out different combinations.

I am not a developer, so feel free to review the code and adapt/correct it. Needs optimizing.

1 Like

Step one: I am mostly interested having our upcoming Whonix host operating system raw (?) image being bootable on both, BIOS and UEFI. As fully persistent (if not using grub-live option in grub boot menu). (i.e. not live-boot based.) Ideally, a single hybrid image, if sane and doable.

Step two: If it could be at the same time a hybrid image that can be burned on DVD, all the better. ISO / DVD support would be step two.

Finally, probably not doable: one image for all use cases HDD persistent, HDD live, DVD live. (DVD-RW persistent realistic?)

Could you please add copyright/license?

from Tails-Whonix: It's doable, here's how. Can we offer it as a variant like Qubes-Whonix?

Yes, a good name for Whonix Host is needed as Whonix Host alone isn’t very descriptive / not sounding very exciting.

Whonix Live (https://www.whonix.org/wiki/Whonix_Live) isn’t very popular yet since Whonix 15 hasn’t been released as stable yet. Nothing written in stone yet. So we could “hijack” our own name, move https://www.whonix.org/wiki/Whonix_Live to elsewhere and then use Whonix Live for the Whonix Host.

What I don’t like about Whonix Live is that it sounds too limited too.

  • It’s not only Live.
  • The great thing is, we can combine the best of both worlds. Boot into persistent mode, upgrade everything and on demand reboot into Live mode.
  • It’s also based on hardened debian (rename required) which comes with many enhanced default security enhancement such as jitterentropy-rng installed by default.

Whonix Host name suggestions welcome.

1 Like

Correction: mostly non-networked. For updates you would of course need to enable networking on the host temporarily.

Thanks for the script. Do you know if the isos work with secure boot enabled?

HDD persistent + live is doable. But not at the same time with an iso file for DVDs. You can burn the iso to an USB stick but it will not be writable in the first place. There is the persistent feature for live tools but for system updates it is imho not really usable. Also, at least from reading the /r/tails, it seems to break occassionaly and people loose their data.
Maybe one could create some kind of installer iso which installs Whonix on the disk and otherwise acts as live CD.

2 Likes