Hi
is there a strong performance-wise reason for "Strict user copy checks: Disabled" - IMHO if something may make things more secure while not have a dramatically performance impact security in doubt should go first __________________________________________________
[root@rh:~]$ checksec --kernel * Kernel protection information:
Description - List the status of kernel protection mechanisms. Rather than inspect kernel mechanisms that may aid in the prevention of exploitation of userspace processes, this option lists the status of kernel configuration options that harden the kernel itself against attack.
Kernel config: /boot/config-3.9.10-200.fc18.x86_64
Warning: The config on disk may not represent running kernel config!
GCC stack protector support: Enabled Strict user copy checks: Disabled Enforce read-only kernel data: Enabled Restrict /dev/mem access: Enabled Restrict /dev/kmem access: Enabled
On Tue, Jul 16, 2013 at 03:39:35PM +0200, Reindl Harald wrote:
Hi
is there a strong performance-wise reason for "Strict user copy checks: Disabled" - IMHO if something may make things more secure while not have a dramatically performance impact security in doubt should go first
iirc, it was disabled in the past because it broke the build, and no-one had the time to fix up the broken drivers.
Dave
On Wed, 2013-07-17 at 15:25 -0400, Dave Jones wrote:
On Tue, Jul 16, 2013 at 03:39:35PM +0200, Reindl Harald wrote:
is there a strong performance-wise reason for "Strict user copy checks: Disabled" - IMHO if something may make things more secure while not have a dramatically performance impact security in doubt should go first
Are that the checks enabled by CONFIG_DEBUG_STRICT_USER_COPY_CHECKS? If so, they don't do anything on x86_64 (which Harald seems to be using), do they?
And please note that on x86_32 one will still see compiler warnings if that Kconfig symbol is not set.
And also note that recently (I think since v3.10, but I haven't checked) actually no copy_from_user() related warnings show up when building for x86_32 and using Fedora-based .config. At least, they don't show up anymore when I build locally. I'm not sure what caused that.
Paul Bolle
Am 22.07.2013 22:29, schrieb Paul Bolle:
On Wed, 2013-07-17 at 15:25 -0400, Dave Jones wrote:
On Tue, Jul 16, 2013 at 03:39:35PM +0200, Reindl Harald wrote:
is there a strong performance-wise reason for "Strict user copy checks: Disabled" - IMHO if something may make things more secure while not have a dramatically performance impact security in doubt should go first
Are that the checks enabled by CONFIG_DEBUG_STRICT_USER_COPY_CHECKS? If so, they don't do anything on x86_64 (which Harald seems to be using), do they?
honestly i have no idea
i started to use checksec / hardening-check for make sure any of my network services are proper hardened and saw this below and thought no mistake to ask :-)
[root@srv-rhsoft:~]$ checksec --help Usage: checksec [OPTION]
Options:
--file <executable-file> --dir <directory> [-v] --proc <process name> --proc-all --proc-libs <process ID> --kernel --fortify-file <executable-file> --fortify-proc <process ID> --version --help
[root@srv-rhsoft:~]$ checksec --kernel * Kernel protection information:
Description - List the status of kernel protection mechanisms. Rather than inspect kernel mechanisms that may aid in the prevention of exploitation of userspace processes, this option lists the status of kernel configuration options that harden the kernel itself against attack.
Kernel config: /boot/config-3.9.10-200.fc18.x86_64
Warning: The config on disk may not represent running kernel config!
GCC stack protector support: Enabled Strict user copy checks: Disabled Enforce read-only kernel data: Enabled Restrict /dev/mem access: Enabled Restrict /dev/kmem access: Enabled
* grsecurity / PaX: No GRKERNSEC
The grsecurity / PaX patchset is available here: http://grsecurity.net/
* Kernel Heap Hardening: No KERNHEAP
The KERNHEAP hardening patchset is available here: https://www.subreption.com/kernheap/
On Mon, 2013-07-22 at 22:35 +0200, Reindl Harald wrote:
Am 22.07.2013 22:29, schrieb Paul Bolle:
Are that the checks enabled by CONFIG_DEBUG_STRICT_USER_COPY_CHECKS? If so, they don't do anything on x86_64 (which Harald seems to be using), do they?
honestly i have no idea
i started to use checksec / hardening-check for make sure any of my network services are proper hardened and saw this below and thought no mistake to ask :-)
I missed that you already mentioned checksec in your original message. But if I had noticed that, it wouldn't have mattered much, because until very recently I never heard of it. But it turns out it is even included in Fedora 18!
grep -B 2 -A 5 CONFIG_DEBUG_STRICT_USER_COPY_CHECKS /usr/bin/checksec
printf " Strict user copy checks: " if $kconfig | grep -qi 'CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y'; then printf "\033[32mEnabled\033[m\n" else printf "\033[31mDisabled\033[m\n" fi
So, it appears to be a straightforward grep for CONFIG_DEBUG_STRICT_USER_COPY_CHECKS.
But it isn't very useful to grep a /boot/config-* file for that macro. For instance, it turns out that on x86_64 CONFIG_DEBUG_VM is actually relevant, as it is that macro that enables a _runtime_ warning for copy_from_user() issues. At least, it did, until it was decided that GCC 4.6+ isn't doing the necessary build time test correctly. Now that _runtime_ check will never be triggered, won't it? So, even if CONFIG_DEBUG_STRICT_USER_COPY_CHECKS was set, and checksec would print a nice, and colorful, "Enabled" for this check, in practice that would currently tell you nothing.
I haven't looked at the other greps for Kconfig macros in checksec. But, looking just at this example, we might consider disabling these greps for checksec in Fedora.
Paul Bolle
On Mon, 2013-07-22 at 22:29 +0200, Paul Bolle wrote:
And also note that recently (I think since v3.10, but I haven't checked) actually no copy_from_user() related warnings show up when building for x86_32 and using Fedora-based .config. At least, they don't show up anymore when I build locally. I'm not sure what caused that.
That seems to be caused by commit 2fb0815c9ee6b9ac50e15dd8360ec76d9fa46a22 ("gcc4: disable __compiletime_object_size for GCC 4.6+"), which was indeed released with v3.10. So, apparently, the copy_from_user() checks need a GCC fix to be useful in the first place, at least for current Fedora releases (as Fedora 18 is already at GCC 4.7.2).
Paul Bolle
kernel@lists.fedoraproject.org
-
Dave Jones -
Paul Bolle -
Reindl Harald