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:51:45 +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:42:37PM +0100, Ingo Molnar wrote:
> 
> * Willy Tarreau <w@....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

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