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.
madaidan via Whonix Forum:
Gather more entropy during boot by madaidan · Pull Request #64 · Kicksecure/security-misc · GitHub
Merged.
Should we make hardened-kernel depend on security-misc? Security-misc provides kernel hardening through sysctls and boot parameters that complement hardened-kernel.
No. That’s not what Debian Depends: are for. Recommends: and
(perhaps Enhances:?) are OK.
HulaHoop via Whonix Forum:
I’m in favor of this because host side solutions will reach limited numbers of users.
I am vary about this approach generally. There are many issues which
cannot be fixed from inside the VM. The root “bug” here is
“non-existence of a Whonix host operating system”. Yet, if we pile up
tons of effort / changes in the inside the VM, we won’t still fix many
issues and delay inception of Whoni host operating system. Therefore,
please rather work towards Whonix host.
This is why we have separate host and VM configs. We can disable hypervisor support in hardened-vm-kernel but keep it enabled in hardened-host-kernel.
madaidan via Whonix Forum:
This is why we have separate host and VM configs. We can disable hypervisor support in hardened-vm-kernel but keep it enabled in hardened-host-kernel.
My last comment applies to that too. Development / review time spend in
inside-VM will at best still be incomplete seems to be the inferior way
to inventing Kicksecure host; and Whonix host.
https://lore.kernel.org/kernel-hardening/20200205223950.1212394-1-kristen@linux.intel.com/
There’s work on making KASLR more fine-grained and resistant to info leaks.
What’s the point of the “#### meta start” lines in etc/sysctl.d/30_security-misc.conf?
madaidan via Whonix Forum:
What’s the point of the “#### meta start” lines in etc/sysctl.d/30_security-misc.conf?
To be used in future for auto generation of design documentation. Not
done for subject of security but done for subject of networking. See: