We can increase the number of iterations if you want but I think the default is enough (3 passes with random data plus the extra pass with zeroes).
madaidan via Whonix Forum:
Merged. Could you please expand the description a bit? Add these links
from the pull request? Add a few more keywords such as kernel, console
and what this might break? This is if ever any bug is reported, Whonix
source code can be grepped and this would give a hint.
Seems one of the lesser known hardening options. By performing web
searches other websites come up who are already similarly thorough at
flipping all the security hardening knobs.
Is there something useful here…?
madaidan via Whonix Forum:
Avoid holes in IOMMU by madaidan · Pull Request #61 · Kicksecure/security-misc · GitHub
Merged.
madaidan via Whonix Forum:
Shred System.map files by madaidan · Pull Request #62 · Kicksecure/security-misc · GitHub
Merged.
We can increase the number of iterations if you want but I think the default is enough (3 passes with random data plus the extra pass with zeroes).
Yes, that is OK. (Much more important to compile the kernel on the
user’s machine and never write a system.map file in first place but that
takes a while until ⚓ T960 hardened kernel Debian packaging and APT integration - hkapt is done.)
“rm --verbose” was OK (I like these features to self-document) but
“shred --verbose” is a bit too chatty. Example:
shred --verbose --force --zero -u /tmp/a
shred: /tmp/a: pass 1/4 (random)…
shred: /tmp/a: pass 2/4 (random)…
shred: /tmp/a: pass 3/4 (random)…
shred: /tmp/a: pass 4/4 (000000)…
shred: /tmp/a: removing
shred: /tmp/a: renamed to /tmp/0
shred: /tmp/a: removed
Changed:
Do you have good references to warn against nested virtualization?
I added “TTY” which should be enough. This shouldn’t really break anything for ordinary users.
The only others who use this that I know of are CLIP OS.
I don’t know much about that. @HulaHoop might.
Doesn’t seem to be anything we don’t already have/not in our kernel version/we’re already working on.
Unrelated, but we might want to use the extra_latent_entropy boot parameter. linux-hardened adds an optional feature to gather more entropy although at a boot speed decrease Add the extra_latent_entropy kernel parameter · anthraxx/linux-hardened@0ca98c2 · GitHub
madaidan via Whonix Forum:
Document ldisc_autoload better by madaidan · Pull Request #63 · Kicksecure/security-misc · GitHub
Merged.
Sounds good! Please add.
Related:
The presentation on the vivid bugs discussed a while ago.
security-misc blacklists the module, hardened-kernel doesn’t include vivid or userfaultfd() (which was used to exploit these bugs) at all, and both restrict the kernel logs to root which mitigates this on multiple layers (although vivid wasn’t removed until these bugs were disclosed).
I’m not aware of it ever being mentioned as adding extra attack surface or aiding spectre/meltdown. Have you seen anything? If yes I can try harder to search for it.
Having multiple OSes/virtualization layers running at the same time does substantially increase attack surface.
I don’t think it’d aid spectre/meltdown, but nested virtualization can definitely be made useless by it as it bypasses everything at once.
Citation needed. It shouldn’t make the host anymore vulnerable than it already is as far as the outer virtual layer is concerned.
+1 if isolation is broken doesn’t matter how many times you use it on itself.
The more code there is running, the more attack surface there is. By using nested virtualization, you’re at least, tripling the amount of code.
I have seen this before but cannot easily find a reference now. Some starting points.
Increased attack surface is a good argument indeed. Specifically so when mixing different virtualizers as a user recently mixed VMware running on a Windows host, VM was running Debian which was then running VirtualBox.
KVM does not allow nested virtualization by default?
Security hardening guides recommend to and security hardened operating systems disable kernel module loading and kexec. The idea of Untrusted Root - improve Security by Restricting Root. But by allowing nested virtualization we allow (untrusted) root or even the user to run any kernel image and to influence which code interacts with the hypervisor directly? That are quite higher privileges and more low level than what (untrusted) root or user could do otherwise?
i.e. exposing the attack surface of the hypervisor to the user?
We can probably remove hypervisor support in hardened-vm-kernel so it can only function as a guest, removing that attack surface.
It’s not really comparable to module loading and kexec though. Those run arbitrary code directly in kernel mode. The guest VM is still isolated.
There’s no simple way for me to know which virtualization layer this second “untrusted root” interacts with. therefore easier to disable the nesting module on the host and get it over with.
I can look further into restricting the vtx/svm cpu flags for guests, but I am not sure this is possible when host cpu is passed thru.
I’m in favor of this because host side solutions will reach limited numbers of users.
Should we make hardened-kernel depend on security-misc? Security-misc provides kernel hardening through sysctls and boot parameters that complement hardened-kernel.