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.
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?
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.
Should we make hardened-kernel depend on security-misc? Security-misc provides kernel hardening through sysctls and boot parameters that complement hardened-kernel.
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.
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.