This bug is for tracking all that we may wish to fix in the next release of hardened-sources (with 2.6.23-r7 being the most current release).
Reminder: add commit 900cf086fd2fbad07f72f4575449e0d0958f860f from upstream if it is not accepted for the stable queue. http://bugs.gentoo.org/show_bug.cgi?id=209460#c20
I will attempt to backport the fixes for bug 198051 to 2.6.23 when I get some time. If it works, I will submit a patch against a clean hardened-sources-2.6.23-r7 tree for your testing. If not, I'll leave a comment in the negative so as not to hold anything up. http://bugs.gentoo.org/show_bug.cgi?id=198051
i vote for this [PATCH] x86: introduce /dev/mem restrictions with a config option http://lwn.net/Articles/267427/
KERNEXEC should probably only be enabled on x86 because otherwise module.c will look for a header file that doesn't exist on most arches: #ifdef CONFIG_PAX_KERNEXEC #include <asm/desc.h> #endif Currently it is also enabled on ppc if the security level is set to 'high' (GRKERNSEC_HIGH) or 'gentoo' (GRKERNSEC_HARDENED). In grsecurity/Kconfig the following substitution should do the trick: --- grsecurity/Kconfig.old 2008-02-14 22:07:34.000000000 +0100 +++ grsecurity/Kconfig 2008-02-14 22:07:57.000000000 +0100 @@ -143,7 +143,7 @@ select PAX_EI_PAX select PAX_PT_PAX_FLAGS select PAX_HAVE_ACL_FLAGS - select PAX_KERNEXEC if (!X86_64 && !EFI && !COMPAT_VDSO && !PARAVIRT && X86_WP_WORKS_OK) + select PAX_KERNEXEC if (X86 && !EFI && !COMPAT_VDSO && !PARAVIRT && X86_WP_WORKS_OK) select PAX_MEMORY_UDEREF if (!X86_64 && !COMPAT_VDSO) select PAX_RANDKSTACK if (X86_TSC && !X86_64) select PAX_SEGMEXEC if (X86 && !X86_64) @@ -235,7 +235,7 @@ select PAX_EMUTRAMP if (PARISC) select PAX_ETEXECRELOCS if (ALPHA || IA64 || PARISC) select PAX_HAVE_ACL_FLAGS - select PAX_KERNEXEC if (!X86_64 && !HOTPLUG_PCI_COMPAQ_NVRAM && !PCI_BIOS) + select PAX_KERNEXEC if (X86 && !HOTPLUG_PCI_COMPAQ_NVRAM && !PCI_BIOS) select PAX_MPROTECT select PAX_NOEXEC select PAX_PAGEEXEC if (!X86)
> I will attempt to backport the fixes for bug 198051 to 2.6.23 when I get some > time. Attached this work to bug 198051.
(In reply to comment #4) > + select PAX_KERNEXEC if (X86 && !HOTPLUG_PCI_COMPAQ_NVRAM && !PCI_BIOS) Uhm.. better make that "select PAX_KERNEXEC if (X86 && !X86_64 && !HOTPLUG_PCI_COMPAQ_NVRAM && !PCI_BIOS)". Don't want to break amd64 I suppose.
Created attachment 143577 [details] patch to fix grsec Kconfig
(In reply to comment #3) > i vote for this [PATCH] x86: introduce /dev/mem restrictions with a config > option grsecurity already provides far more comprehensive protection with the GRKERNSEC_KMEM and GRKERNSEC_IO options. Here is an excerpt from the help for the former option: "If you say Y here, /dev/kmem and /dev/mem won't be allowed to be written to via mmap or otherwise to modify the running kernel. /dev/port will also not be allowed to be opened ... Though nothing legitimately writes to /dev/kmem, XFree86 does need to write to /dev/mem but only to video memory, which is the only writing we allow in this case." Not to mention that the presentation of these options to the user is also considerably more clear.
A prospective 2.6.23-r8 release can be found at http://confucius.dh.bytemark.co.uk/~kerin.millar/ which closes all issues mentioned here and in the blocking bugs. Furthemore, there is now a "trunk" sub-directory which contains the split-out patches. Testing would be most welcome. Changes: * Add all current patches from the 2.6.23 stable queue * Resolves bugs 197626, 198051, 199874, 208331, 210022 and 210138 * Drop 4480_x86_64-bogus-acpi-symbols-defconfig.patch (the situation with default config files is a sorry mess and should, ideally, be addressed more comprehensively) * Only select KERNEXEC on x86 in GRKERNSEC_HIGH and GRKERNSEC_HARDENED grsecurity profiles (see bug 210026). On another note, I'll be uploading a 2.6.24 release shortly.
may be, we should add fixes from upstream: http://www.eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.23.17 I see the inode bug as problematic.
comment #9 has been included as-is
(In reply to comment #10) > may be, we should add fixes from upstream: The patch you mention was already included. I added all patches from the stable queue at the time of preparation. These patches are exactly the same set of patches that collectively constitute the 2.6.23.17 patch. I notice that dsd bumped genpatches very recently. As such, the only patch that's missing from there is 4001_e1000e-crc-stripping.patch.
