Until some 3.9.* version sys-kernel/hardened-sources did not have this dep: linux # grep X86_MSR ./arch/x86/Kconfig -A3 config X86_MSR tristate "/dev/cpu/*/msr - Model-specific register support" depends on !GRKERNSEC_KMEM ---help--- It was possible to protect /dev/kmem /dev/mem /dev/port and use powertop, but now it is not. It is still possible to protect (aka remove) /dev/kmem by disabling CONFIG_DEVKMEM and make /dev/mem read only with CONFIG_STRICT_DEVMEM=y, but it seems not possible to disable /dev/port and enable additional checks added when CONFIG_GRKERNSEC_KMEM is defined. I need powertop, but i would like to use as secure kernel as possible.
It is straightforward to decouple kmem and msr with the following patch, but i'm not sure what the consequences would be. I'll pass the question by upstream. ' diff -Naur linux-3.11.8-hardened/arch/x86/Kconfig linux-3.11.8-hardened.orig/arch/x86/Kconfig --- linux-3.11.8-hardened/arch/x86/Kconfig 2013-11-26 11:07:49.023038486 -0500 +++ linux-3.11.8-hardened.orig/arch/x86/Kconfig 2013-11-17 13:50:01.792291860 -0500 @@ -1088,6 +1088,7 @@ config X86_MSR tristate "/dev/cpu/*/msr - Model-specific register support" + depends on !GRKERNSEC_KMEM ---help--- This device gives privileged processes access to the x86 Model-Specific Registers (MSRs). It is a character device with
this is a preemptive measure until someone analyzes every single MSR and determines whether the ones capable of compromising the kernel are under proper access control.
(In reply to PaX Team from comment #2) > this is a preemptive measure until someone analyzes every single MSR and > determines whether the ones capable of compromising the kernel are under > proper access control. I understand, but does it make sense to lump it in with GRKERNSEC_KMEM. Could we have an independant GRKERNSEC_MSR?
(In reply to Anthony Basile from comment #3) > (In reply to PaX Team from comment #2) > > this is a preemptive measure until someone analyzes every single MSR and > > determines whether the ones capable of compromising the kernel are under > > proper access control. > > I understand, but does it make sense to lump it in with GRKERNSEC_KMEM. > Could we have an independant GRKERNSEC_MSR? @pipacs. It doesn't look like you did anything with this. Is it still an issue?
(In reply to Anthony Basile from comment #4) > > I understand, but does it make sense to lump it in with GRKERNSEC_KMEM. > > Could we have an independant GRKERNSEC_MSR? > > @pipacs. It doesn't look like you did anything with this. Is it still an > issue? this is spender's call as this restriction is in grsec, not PaX per se ;).
Unless you need access to /dev/mem, you can disable both DEVMEM and DEVKMEM. Is /dev/port still a thing? If not, that may be a workaround allowing you to turn off GRKERNSEC_KMEM. This has been my plan to get cpupower working on our servers.
