All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frank.rowand@am.sony.com>
To: Marcus Meissner <meissner@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jason.wessel@windriver.com" <jason.wessel@windriver.com>,
	"fweisbec@gmail.com" <fweisbec@gmail.com>,
	"tj@kernel.org" <tj@kernel.org>, "mort@sgi.com" <mort@sgi.com>,
	"akpm@osdl.org" <akpm@osdl.org>,
	"security@kernel.org" <security@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking
Date: Thu, 4 Nov 2010 19:38:57 -0700	[thread overview]
Message-ID: <4CD36E41.50505@am.sony.com> (raw)
In-Reply-To: <20101104122906.GH25118@suse.de>

On 11/04/10 05:29, Marcus Meissner wrote:
> On Thu, Nov 04, 2010 at 12:46:48PM +0100, Ingo Molnar wrote:
>>
>> * Marcus Meissner <meissner@suse.de> wrote:
>>
>>> Hi,
>>>
>>> Making /proc/kallsyms readable only for root makes it harder for attackers to 
>>> write generic kernel exploits by removing one source of knowledge where things are 
>>> in the kernel.

< snip >

>> So what does a distribution like Suse expect from this change alone? Those have 
>> public packages in rpms which can be downloaded by anyone, so it makes little sense 
>> to hide it - unless _all_ version information is hidden.
> 
> It is the first patch, mostly an acceptance test balloon.
> 
> There are several other files handing information out, but kallsyms has
> it all very nice and ready.
> 
> (timer_list, /proc/*/stat*, sl?binfo )
>  
>> So i'd like to see a _full_ version info sandboxing patch that thinks through all 
>> the angles and restricts uname -r kernel version info as well, and makes dmesg 
>> unaccessible to users - and closes a few other information holes as well that give 
>> away the exact kernel version - _that_ together will make it hard to blindly attack 
>> a very specific kernel version.
> 
> I am personally thinking of a "small steps" philosophy, one step after the other.

< snip >

The idea of trying to hide the kernel version is absurd.  The number of different
places that can provide a precise fingerprint of a kernel version, or a small range of
possible kernel versions is immense.  Closing all of those places makes use and
administration of a system more difficult, and encourages frequent use of su.

Dumb examples of version clues (beyond the obvious simple ones):

$ gcc -v
Target: x86_64-redhat-linux
gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)

$ rpm -qi gcc
Release     : 10.fc13                       Build Date: Wed Jun 30 02:54:10 2010

$ rpm -qi kernel
Version     : 2.6.33.3                          Vendor: Fedora Project
Release     : 85.fc13                       Build Date: Thu May  6 11:35:36 2010

$ ls -l /lib64
$ ls -l /boot
$ lsmod


-Frank


  parent reply	other threads:[~2010-11-05  2:39 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-04 10:09 [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking Marcus Meissner
2010-11-04 10:11 ` Tejun Heo
2010-11-05  0:11   ` [Security] " Eugene Teo
2010-11-04 11:46 ` Ingo Molnar
2010-11-04 12:29   ` Marcus Meissner
2010-11-04 13:58     ` Ingo Molnar
2010-11-04 14:11       ` Ingo Molnar
2010-11-04 14:33         ` Marcus Meissner
2010-11-04 14:38           ` Tejun Heo
2010-11-04 14:43             ` H. Peter Anvin
2010-11-04 14:48               ` Tejun Heo
2010-11-04 19:08           ` Ingo Molnar
2010-11-04 21:29             ` [Security] " Willy Tarreau
2010-11-04 21:51               ` Ingo Molnar
2010-11-04 22:35                 ` Willy Tarreau
2010-11-04 23:46                   ` Willy Tarreau
2010-11-07  8:50                   ` Ingo Molnar
2010-11-07  9:08                     ` Ingo Molnar
2010-11-07  9:49                     ` Willy Tarreau
2010-11-07 11:27                       ` Ingo Molnar
2010-11-07 11:41                         ` Willy Tarreau
2010-11-07 11:47                           ` Ingo Molnar
2010-11-07 11:56                             ` Willy Tarreau
2010-11-07 12:12                               ` Ingo Molnar
2010-11-07 12:22                                 ` Willy Tarreau
2010-11-07 12:25                                   ` Ingo Molnar
2010-11-07 12:39                                     ` Willy Tarreau
2010-11-07 12:32                                   ` Ingo Molnar
2010-11-07 12:51                                     ` Willy Tarreau
2010-11-07 15:27                                     ` Alan Cox
2010-11-08  6:29                                       ` Ingo Molnar
2010-11-07 11:42                       ` Ingo Molnar
2010-11-07 11:51                         ` Willy Tarreau
2010-11-07 12:37                           ` Ingo Molnar
2010-11-07 12:55                             ` Willy Tarreau
2010-11-07  8:56                   ` Ingo Molnar
2010-11-07  9:03                   ` Ingo Molnar
     [not found]               ` <20101104215157.GA25128@ <20101107090805.GA27983@elte.hu>
2010-11-13 13:06                 ` Gilles Espinasse
2010-11-07 18:02           ` Andi Kleen
2010-11-07 18:32             ` H. Peter Anvin
2010-11-10  8:53               ` Ingo Molnar
2010-11-11  2:51                 ` H. Peter Anvin
2010-11-11  7:05                   ` Ingo Molnar
2010-11-05  2:38     ` Frank Rowand [this message]
2010-11-10 20:58       ` Jesper Juhl
2010-11-05  0:20 ` Jesper Juhl
  -- strict thread matches above, loose matches on Subject: below --
2010-11-16 10:46 Marcus Meissner
2010-11-17  5:07 ` Kyle McMartin
2010-11-18  7:48   ` Ingo Molnar
2010-11-20  3:18     ` Kees Cook
2010-11-26  7:51       ` Ingo Molnar
2010-11-17  5:40 ` Kyle Moffett
2010-11-17  5:41   ` Kyle Moffett
2010-11-17  5:58   ` Linus Torvalds
2010-11-17  6:19     ` Willy Tarreau
2010-11-18  7:31   ` Ingo Molnar
2010-11-23 17:24     ` Pavel Machek
2010-11-26  7:38       ` Ingo Molnar
2010-11-29 19:03         ` H. Peter Anvin
2010-11-20 11:32   ` Avi Kivity
2010-11-19 19:19 ` Sarah Sharp
2010-11-19 19:54   ` Linus Torvalds
2010-11-19 19:58     ` david
2010-11-19 20:04       ` Linus Torvalds
2010-11-19 20:16         ` Willy Tarreau
2010-11-19 20:55           ` david
2010-11-26  7:48     ` Ingo Molnar
2010-11-29 16:33       ` Sarah Sharp
2010-11-29 18:04         ` Ingo Molnar
2010-11-29 19:05           ` H. Peter Anvin
2010-11-29 19:21             ` Eric Paris
2010-11-29 19:38               ` H. Peter Anvin
2010-11-29 21:49             ` Willy Tarreau
2010-11-29 23:31         ` Alan Cox
2010-11-30 11:58           ` Ingo Molnar
2010-11-20 11:05 ` Richard W.M. Jones
2010-11-19 21:12 Andy Walls
2010-11-19 23:22 ` Linus Torvalds
2010-11-20  2:40   ` Kees Cook
2010-11-20 19:47     ` Henrique de Moraes Holschuh
2010-11-29 22:58       ` Kevin Easton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD36E41.50505@am.sony.com \
    --to=frank.rowand@am.sony.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=akpm@osdl.org \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=meissner@suse.de \
    --cc=mingo@elte.hu \
    --cc=mort@sgi.com \
    --cc=security@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.