lkml.org 
[lkml]   [2010]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking
On Sun, Nov 07, 2010 at 12:42:37PM +0100, Ingo Molnar wrote:
>
> * Willy Tarreau <w@1wt.eu> wrote:
>
> > [...] I was explaining that doing this will not prevent them from guessing the
> > precise kernel version, [...]
>
> Well, which is exactly what i have said to Marcus early on in this discussion:
>
> |
> | What i suggested in later parts of my mail might provide more security: to sandbox
> | kernel version information from unprivileged user-space - if we decide that we
> | want to sandbox kernel version information ...
> |
> | That is a big if, because it takes a considerable amount of work. Would be worth
> | trying it - but feel-good non-solutions that do not bring much improvement to the
> | majority of users IMHO hinder such efforts.
> |
>
> The 'considerable amount of work' refers not to the utsname version fuzzing patch
> (it's a 10-liner patch, literally), but to controlling the channels of version
> information you mentioned (uptime, the /boot timestamp), and some other channels you
> did not mention: dmesg, various /sys and /proc entries that leak version
> information, etc.

I did not mention dmesg because it's already sometimes hidden from users (eg,
when iptables logs there).

> All must be closed down for unprivileged user-space, for this to be effective,
> obviously.

This would only be effective against finding a precise version. There's
no need for that, what you want is to hide kernel pointers, and your issue
is that in distro kernels, same kernels have the same pointers. It would be
much more efficient to work on a method to randomize all pointers than to
try to hide a kernel version hoping a user is not able to guess what it is.
Even if you'd hide the uptime, there are many ways to find it. In my opinion,
it's a race in the wrong direction, and which has several negative side
effects on the normal user.

Better attack the problem than its symptoms.

Willy



\
 
 \ /
  Last update: 2010-11-07 12:55    [W:0.070 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site