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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 7 Nov 2010 12:47:56 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Willy Tarreau <w@....eu>
Cc:	Marcus Meissner <meissner@...e.de>, security@...nel.org,
	mort@....com, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	fweisbec@...il.com, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, jason.wessel@...driver.com,
	tj@...nel.org, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to
 reduce ease of attacking


* Willy Tarreau <w@....eu> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/