Anyone had any issues with this?
Now merged. Thank you!
Based on the recently merged:
We are now allowing kexec:
Are we sure that this is a good idea? Recall, kexec functionality can be abused to replace the existing running kernel and load a malicious kernel (gaining arbitrary code execution).
On the plus side, while having cold boot attack defense is good. The real question is whether the tradeoff of having kexec allowed is worth it knowing the potential downsides?
To use kexec, root is required. But if an attack has root access, then it’s game over anyhow.
In a threat model with untrusted root ( Multiple Boot Modes for Better Security: an Implementation of Untrusted Root ) that might be more important.
You could argue that the scope of security-misc should be limited and that cold boot attack defense should be a separate package instead. Then security-misc could disable kexec and cold boot attack defense could re-enable it.
That would allow cold boot attack defense to only be enabled on host operating systems. It would get installed on Kicksecure host operating systems by default but could be omitted in VMs (as it seems it’s not useful there except for development and testing).
That makes sense.
Are there any statistics as to the portion of users that install/download Kicksecure to be used on bare metal vs VMs?
Based on my anecdotal evidence most people run it on VMs, though admittedly its a very very small sample size.
A post was merged into an existing topic: IO_uring security / vulnerabilties?
Noted. I’m posting here about more options for reference in case a challenger appears who could and cares to handle such a project.
IO_uring is a new IO subsystem and is a veritable vuln dumpster fire. The Goog has disabled it on its systems and OSs.
A new 6.6 sysctl is developed just to disable it on boot which we should take advantage of ASAP.
Overall, a very interesting set of discussions and suggestions!
I am also trying to catch up on the all details to see whether I can offer any feedback.