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:
Bluetooth is blacklisted to reduce attack surface. Bluetooth also has a history of security concerns. Bluetooth - Wikipedia
hotwater:
This is a very sharp decision. Many users use bluetooth for different purposes, like bluetooth speakers, mouses, keyboards, and other pieces of hardware.
Although bluetooth had many critical flaws, their core recommendations always admonish how to resist. Like the KNOB vulnerability which had a place on all bluetooth chips 1.0 to 5.1, core specs now say “enforce a minimum encryption key length of 7 octets for BR/EDR connections”.
It’s better to accurately follow the recommendations and not to cut the technology.
Was always wondering if we’d need two more packages. security-misc-vm (where blocking bluetooth makes sense) and security-paranoid (more experimental, more likely breaking things, probably non-default, optionally installed package).
The days of hidepid=2 might be counted.
With wayland it will be no longer possible to run applications as root. I.e.lxsudo will no longer work. Source:
Running GUI applications as root - ArchWiki
Therefore also pkexec wrapper (redirecting to lxsudo) will no longer work. I.e. when using wayland, no more pkexec based applications could be used.
And what’s more important? Wayland or hidepid? I guess wayland. (At some point
Also due to other bugs… cannot use pkexec