A series of scripts for downloading, verifying, and installing KVM Whonix on Debian. - juxtin/install-whonix
Did we ever see this one? I don’t remember? Wondering why its author never contacted us?
(It’s gpg verification code might be unsafe in fully automated scripts. -> Should use https://github.com/Whonix/gpg-bash-lib style.)
Done. Changed it for all commands however some command outputs are just left as pre as no one is expected to copy paste those. I didn’t realize how much info was added over the years until I went thru it all to change it. 
Never. He didn’t contact us either, but it’s definitely an interesting building block for a “KVM installer” once the crypto stuff gets sorted out.
I don’t think it gets sorted out. And maybe also not needed for Whonix KVM Host / whonix-host-kvm.
For Whonix KVM Host we could copy over the files during a build-step.
For sudo apt-get install whonix-host-kvm on Debian hosts it looks more complicated. We’d need a deb package shipping the qcow2 files. Not sure that would be crazy.
Good.
Will there be a Whonix host meta-package for vanilla Debian hosts that includes as much securtiy specific and privacy enhancements as applicably possible? This is doubly relevant for a hardened Debian VM which can also act as a sandbox for the browser that accesses captive portals.
Will there be a Whonix host meta-package for vanilla Debian hosts that includes as much security specific and privacy enhancements as applicably possible?
Yes. It’s required for a Whonix-KVM-Host anyhow.
hardened-debian-host-kvm-xfce (rename required) (not sure in which order the name, getting a lot: host vs VM, kvm vs virtualbox, xfce vs cli)whonix-host-kvm (depending on hardened-debian-host-kvm-xfce most likely to avoid code duplication, that’s a clean way to implement it anyhow)But I am not sure yet a whonix-host-kvm meta package (installable on Debian hosts or default installed meta package on a Whonix-KVM-Host) could be capable of fetching Whonix qcow2 images since we don’t have a Debian package(s) which which ships qcow2 images, and I am not sure yet it’s sane to create them.
This is doubly relevant for a hardened Debian VM which can also act as a sandbox for the browser that accesses captive portals.
Interesting idea, so we could ship the hardened Debian VM by default on a Whonix-Host too.
Are these two packages available anywhere? I’m building a new host and it sounds like this could save me some time.
No, for now it’s only a development discussion.
This page is strange. When I edit the steps 1 and 2 don;t appear in the page source just the broken template link. If I paste the proper download table template, it replaces everything.
Somewhat(?) fixed. See now please.
Looks good now 
Could you invite this guy here to join development please? https://github.com/juxtin/install-whonix
Qubes does something similar. Qubes ships rpm (similar deb) packages with VM images.
The problem with such a package is if used just as regular package:
Issue B) could be solved by not using the file from the package but by using a copy of that file originating from such a package. But then we are at issue C):
the package would get getting upgraded (wasting download time and download quota)
Qubes (dom0 is Fedora based) solves this issue by disabling upgrading of the package. It can be done on Debian too using sudo apt-mark hold package-name. On Debian that would lead to a probably user confusing message during sudo apt-get dist-upgrade. For example:
The following packages have been kept back:
whonix-vm-image-kvm
That would allow users to stick with whatever vm image they got earlier and keep their modifications. That would also allow users to easily re-install their vm image (thereby loosing all image modification) by using apt-unhold, apt-get dist-upgrade, apt-hold (re-block from upgrading).
Changes for Buster hosts:
RAM will be allocated as needed. Should make resource use more efficient.
Upon guest termination, all memory should be wiped this should be a nice anti-forensic feature against “warm” RAM attacks for guests that were running in live mode. Linux cleans RAM only when it is about to be resused by another process. This ensures no info from the guest RAM is floating around after guest is off.
Switched RNG to urandom where rate limiting is not critical because the interface doesn’t block (jitterentropy-rngd should be on the host for best results)
Only a line-out/speaker is attached to VMs microphone not available by default. Instructions will be added to reverse this for users who want VoIP.
EDIT:
Re-enabled pvspinlock for better vvcpu performance and reduced code-path use
Excluded Guest RAM contents from any memory dumps on hosts that have coredumps enabled in case libvirt crashes(Debian does not)
*https://github.com/Whonix/whonix-libvirt/pull/87/commits/704972ae4654fa635703101929f575176ce7f4af
*https://github.com/Whonix/whonix-libvirt/pull/88/commits/fd5e8cd3d8544e8e3c829a04174abf15509cbf51
*https://github.com/Whonix/whonix-libvirt/pull/89/commits/47503dae7161694627327eed3cc4a16e5ced7864
*https://github.com/Whonix/whonix-libvirt/pull/90/commits/fb6a7143b4cdf2390e5547390f383458cb8eb590
A new build will be available soon.
This https://github.com/Whonix/whonix-libvirt/pull/87/files#r301910383 i.e. setting from
<backend model='random'>/dev/random</backend>
to
<backend model='random'>/dev/urandom</backend>
has to be carefully considered.
Is this recommended / discussed somewhere?
What would happen in the guest if /dev/random on the host (“backend”) blocks?
With havegend and/or jitterentropy-rngd installed on the host, neither /dev/random nor /dev/urandom seem to ever block.
Even without havegend and/or jitterentropy-rngd installed on the host, are inside VM issues, i.e. /dev/random entropy blocking/exhaustion issues ever been reported or reproducible?
If https://www.whonix.org/wiki/Dev/Entropy#.2Fdev.2Frandom_vs._.2Fdev.2Furandom i.e.
/dev/random vs. /dev/urandom
This debate comes from a misconception by the Linux manual writer. […]
is true, then /dev/random vs. /dev/urandom does not really matter and /dev/urandom would be secure either way.
On the other hand https://www.2uo.de/myths-about-urandom while “being a strong critic of using /dev/random” still concludes
Linux’s /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.
And I like to add: “When is that? At system start, booting the computer, or when there is a bug.”
It depends on how much entropy KVM reads from the virtio-rng backend and when that is happening. Since there probably never were blocking issues due to use of /dev/random instead of /dev/urandom (?), /dev/random seems better to me.
It is recommended in the libvirt manual and is now the default choice for new VMs after backend support was added. The blocking behavior was a big problem.
https://libvirt.org/formatdomain.html#elementsRng
However, the recommended source of entropy is
/dev/urandom(as it doesn’t have the limitations of/dev/random.
In scenarios where a user is running a headless workstation with minimal hardware attached it can be. Some daemons that require entropy can take forever to start if they depend on random.
Both statements are true and there is no contradiction. The only serious difference was during a machine’s early boot. Once started there is no benefit from using random over urandom. Its blocking behavior is sort of a DoS problem where someone can trigger its blocking by drawing entropy in a way that causes it to block. Rate limiting was necessary to stop this but not with urandom.
The difference in practice (random number quality wise) is none because Whonix VMs don’t start early enough in the host boot cycle for it to matter. The blocking action of /dev/random is a performance concern.
It is unlikely most of our users know about jitternetropy to install it on their hosts and so using random over urandom can cause hanging of processes.