Somewhat(?) fixed. See now please.
1 Like
Looks good now 
1 Like
Could you invite this guy here to join development please? GitHub - juxtin/install-whonix: A series of scripts for downloading, verifying, and installing KVM Whonix on Debian.
1 Like
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:
- A) big size
- B) once upgraded (new version), user modifications are lost.
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).
1 Like
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
A new build will be available soon.
1 Like
This More security features on Buster by HulaHoopWhonix · Pull Request #87 · Kicksecure/libvirt-dist · GitHub 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 Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND 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 Myths about /dev/urandom - Thomas' Digital Garden 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.
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.
1 Like
Attempting build, git only shows tags in the version 10 series. Any suggestions what to fix?
HulaHoop via Whonix Forum:
Attempting build, git only shows tags in the version 10 series. Any suggestions what to fix?
Upstream git changed the behavior for git tag and others to
scrolling by default (using arrow keys or so). Similar to (GNU) more
command line utility. So just try pressing arrow keys or git --no-pager tag or git tag | cat.
(Btw also systemd supports --no-pager for example sudo systemd status --no-pager. “Pager by default” seems to be a thing nowadays.)
1 Like
OK I’ll wait for a new developers point release that includes my latest changes before doing it.
1 Like
HulaHoop via Whonix Forum:
OK I’ll wait for a new developers point release that includes my latest changes before doing it.
Not advisable to use developers-only releases, test them and release as
stable:
- packages might have commits without having bumped version number yet.
Other things unfit for release as of time for writing examples:
Is the whonix-libvirt package changes part of 15.0.3.3-stable then?
1 Like
No.
Merged in master but not included in any tag.
1 Like
Wow what a great cleanup effort. Accepted. Thanks to the author.
1 Like
Could you please update Whonix ™ for KVM?
- no more use of keyservers due to gpg --recv-keys fails / no longer use keyservers for anything
- more similar to Whonix ™ Signing Key (most importantly using that super long, unfortunately required, gpg command which is the only one which shows the full key id.
This
gpg --keyid-format long --import --import-options show-only --with-fingerprint hulahoop.asc