Messages in this thread Patch in this message | | | Date | Sun, 7 Nov 2010 09:50:16 +0100 | From | Ingo Molnar <> | Subject | Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking |
| |
* Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Nov 04, 2010 at 10:51:57PM +0100, Ingo Molnar wrote: > > > Quite honnestly, it's the worst idea I've ever read to protect the kernel. Kernel > > > version is needed at many places, when building some code which relies on presence > > > of syscall X or Y depending on a version, etc... [...] > > > > Actually that's not true, since we have a kernel ABI, and since there's many > > backports of newer kernel features into older kernels that it's generally not > > needed nor meaningful to know the kernel version for syscalls. > > > > Returning -ENOSYS is the general standard we use to communicate syscall > > capabilities. > > > > In fact using kernel version to switch around library functionality is a bug i'd > > argue. > > I'm sorry Ingo, but I still don't agree. We've had several versions of epoll, > several (some even buggy) versions of splice() which cannot even be detected > without checking the kernel release. And those are just two that immediately come > to my mind. If we've been providing a version for the last 19 years, it surely had > some valid uses.
I'm sorry Willy, but you are mostly wrong - and there's no need to speculate here really. Just try the patch below :-)
If your claim that 'kernel version is needed at many places' is true then why am i seeing this on a pretty general distro box bootup:
[root@aldebaran ~]# uname -a Linux aldebaran 2.6.99-tip-01574-g6ba54c9-dirty #1 SMP Sun Nov 7 10:24:38 CET 2010 x86_64 x86_64 x86_64 GNU/Linux
?
Yes, some user-space might be unhappy if we set the version _back_ to say 2.4.0, but we could (as the patch below) fuzz up the version information from unprivileged attackers easily.
_Future_ ABI breakages that necessiate a version check are clearly frowned upon, so this patch could even be considered a debugging feature: it makes it harder to create ABI incompatibilities (at least for unprivileged user-space).
So you can think of version fuzzing also as the ultimate ABI check.
( This is a real defensive measure - here's a reason why attackers try stealth remote fingerprinting of a target system first: they really want to avoid detection and knowing the exact OS and version of a target tells them which attacks can be tried with a higher chance of success. Same goes for local attacks as well.
And once we have _that_, version fuzzing, removing kallsyms is one of the many measures we need to use to hide the true version of the kernel from unprivileged user-space. )
Thanks,
Ingo
Index: linux/Makefile =================================================================== --- linux.orig/Makefile +++ linux/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 -SUBLEVEL = 37 -EXTRAVERSION = -rc1 +SUBLEVEL = 99 +EXTRAVERSION = NAME = Flesh-Eating Bats with Fangs # *DOCUMENTATION*
| |