| |||||||||||||
A story of three kernel vulnerabilitiesA story of three kernel vulnerabilitiesPosted Feb 19, 2013 22:05 UTC (Tue) by rahulsundaram (subscriber, #21946)In reply to: A story of three kernel vulnerabilities by Trou.fr Parent article: A story of three kernel vulnerabilities
support for signed kernel modules has existed for a long time and wasn't created because of UEFI. It has been in the distro kernels for years before it got upstream. Specifically, RHEL kernels have been using it. It just got recently upstream however.
(Log in to post comments)
A story of three kernel vulnerabilities Posted Feb 19, 2013 22:59 UTC (Tue) by spender (subscriber, #23067) [Link]
Signed module support is still completely useless unless the /dev/cpu/*/msr vulnerability is fixed properly. Checking for CAP_SYS_RAWIO doesn't cut it.
-Brad
A story of three kernel vulnerabilities Posted Feb 19, 2013 23:37 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
If you're root you've also got access to the MMIO regions of a bunch of devices with DMA engines, so just locking down MSR access isn't going to be a huge win. The Secure Boot work covers most of this, but it's based on the assumption that unless you've got some mechanism for verifying the integrity of your bootloader and on-disk kernel, the security improvement isn't huge - modify the embedded sectors of the bootloader (so tripwire won't pick things up), and just wait for the system to be rebooted for a kernel security update.
Signed module support in RHEL was never about security, it was about supportability. If customers are willing to use MSR hacks to load unsigned modules they're also going to be willing to just modify their bug reports to remove the tainted flags, so making it foolproof was never a great concern.
|
|||||||||||||