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]

Message-ID: <20101107115626.GX4627@1wt.eu>
Date:	Sun, 7 Nov 2010 12:56:26 +0100
From:	Willy Tarreau <w@....eu>
To:	Ingo Molnar <mingo@...e.hu>
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

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

--
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/