Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking

[Willy Tarreau <w@1wt.eu>]

On Sun, Nov 07, 2010 at 12:47:56PM +0100, Ingo Molnar wrote:
> I did read it and saw no valid counter-examples. You mentioned this one:
> 
>  > Take the splice() data corruption bug for instance. I believe it was fixed in 
>  > 2.6.26 or 2.6.27 and backported late in the 2.6.25.X stable branch. Due to this, 
>  > without knowing the kernel version, the user can't know whether it's safe to use 
>  > splice() or not. I'm particularly aware of this one because I got quite a bunch 
>  > of questions from users on this subject. But certainly there are a bunch of other 
>  > ones.
> 
> That example is entirely bogus. The correct answer to a buggy, data-corrupting 
> kernel is a fixed kernel. No ifs and when. No version checks in user-space. If 
> user-space ever works around a bug in that fashion it's entirely broken and 
> _deserves_ to be further broken via version fuzzing.

It's not working around a bug, it's that using splice() instead of
recv()+send() brings an important speed up in some environments, and that
it is suggested to make use of it when possible, except on buggy kernels.
Some user-space code simply have a tunable to enable it or not.

> Do you know of a single such actual vmsplice() version check example in user-space, 
> or have you just made it up?

I was not speaking about vmsplice() but about splice(). And yes it's a real
world example. Haproxy makes use of it when the option is specified. And it
will never enable it automatically due to that nasty data corruption bug
that cannot be detected. Only the user can run "uname -a" and compare with
his distro's fixes (or mainline kernel fixes) and know what to do. Once again
it's just *one* example. A version is beforeall an indication of features and
bugs status.

It's precisely because you're making a special case of the security bug that
you want to hide bugs from user-space by cheating on version.

Willy