Backport Firmware and Kernel | Protect against spectre/meltdown and various hardware vulnurabilities
monsieuremre opened this issue · comments
Ding dong. First and the biggest problem with Debian: package freezing. On some other distros like Fedora, developers are aware of the security implications of freezing packages. Thats why fedora freezes packages, but they don't freeze the kernel, and they don't freeze firmware.
Debian freezes firmware updates between point releases. Ouch. This is supposedly for 'testing'. But this more of a joke really. Because what are you testing? What are you going to do, it is non-free to begin with. Like, there is no point.
My solution: let's port these from sid, by default. I know it is not recommended to make 'FrankenDebian' or whatever, but we already are distromorphing, this is only just the kernel, which is the most backported thing in the universe. The counter argument here can be: oh no the debian security team does not give priority to sid. And this argument would be very moot, because the debian security team does not give any priority to non-free firmware on any of their distros at all, anyway. They just don't do anything. But they still freeze it still, for some reason.
And for the kernel, we really don't need the debian security team to do them security patches. The upstream kernel maintainers are the ones that recognize the security issues and fix them in the first place anyway. And since we are going to get the latest stable release, we are still going to be way faster to receive security updates, along with other bug fixes, which might also impact security, despite not receiving a CVE. All bugs are bad, and can be used against the user. Only patching CVE's is not the best approach, especially for the kernel.
Backport the kernel, backport the firmware. I will go ahead and raise you a more radical solution. It does not take a super genius to compile a kernel. It does not take a genius to write a pipeline to compile the kernel. A buildservice can also be used. The more radical solution is, we do our own kernel. We, as in actually you the maintainer, and not we the user. We won't do any complicated patches that would require review before compile. Just gonna compile with the hardened sysctl defaults, include the non free firmware, sign them all with kicksecure keys, and ship them in a deb package. I tell you. You want big security, this is big security, without having to change the base repo. If you don't trust yourself to maintain this, let's just packport these. Let's go. Waiting for counter arguments if any.
This is more than I can maintain. Written just now:
https://www.kicksecure.com/wiki/Dev/maintainability
My suggestions for you:
- Run an independent project doing hardened Linux kernel.
- Run it for an extended amount of time.
- Find a reliable Open Source business model. Maybe optional.
- Create the the perception and reality of reliability, stability, sustainability, continued existence.
- Simple builds from source code and available binary kernel (APT) repository packages.
Now that grsecurity stable version is no longer available for free, there's certainly a gap in easily available, good usability, well maintained, hardened Linux kernel project space.
If such a hardened kernel project was available and and compatible with Kicksecure, using it would of course be considered. If such as project existed, I'd certainly leave feedback on what is required for it to be usable by Kicksecure.
I know it is not recommended to make 'FrankenDebian' or whatever, but we already are distromorphing,
Not a good argument to mention distromorphing. Sometimes it's useful to invent new terminology but I couldn't foresee what this implies but it might mean a lot less than perceived in context of Kicksecure. I elaborated on that here:
https://www.kicksecure.com/wiki/Distribution_Morphing#Kicksecure
Yes of course you are right, I already guessed this answer. That's why I suggested backporting as the primary option. Debian sid has the latest firmware and kernel. Backporting them as default is not that hard. And maintaining is done by upstream kernel devs, packaging is done by debian. The only thing is just setting this to be the default. Has this been considered before?
Now comes to mind this also contradicts the viewpoint in the wiki:
https://www.kicksecure.com/wiki/Kernel
Closing