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

[Ingo Molnar]

* Willy Tarreau <w@xxxxxx> wrote:

> On Sun, Nov 07, 2010 at 12:27:09PM +0100, Ingo Molnar wrote:
> > > I don't understand the point you're trying to make with this patch. [...]
> > 
> > It was a simple experiement to support my rather simple argument which you disputed.
> 
> OK
> 
> > > [...] Obviously we can pretend to be any version, [...]
> > 
> > Ok, it's a pretty cavalier style of arguing that you now essentially turn around 
> > your earlier claim that the 'kernel version is needed at many places' and say what 
> > i've been saying, prefixed with 'obviously' ;-)
> 
> Huh ?
> 
> > Yes, it's obvious that the kernel version is not needed for many functional purposes 
> > on a modern distro - and that was my exact point.
> > 
> > I cannot think of a single valid case where the proper user-space solution to some 
> > ABI compatibility detail is a kernel version check.
> 
> Ingo, I believe you did not read a single line of my previous mail, because I 
> precisely gave you counter-examples of that. [...]

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.

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

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/