lkml.org 
[lkml]   [2010]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking
On Fri, 19 Nov 2010, Willy Tarreau wrote:

> On Fri, Nov 19, 2010 at 12:04:47PM -0800, Linus Torvalds wrote:
>> On Fri, Nov 19, 2010 at 11:58 AM, <david@lang.hm> wrote:
>>>
>>> how far back do we need to maintain compatibility with userspace?
>>>
>>> Is this something that we can revisit in a few years and lock it down then?
>>
>> The rule is basically "we never break user space".
>>
>> But the "out" to that rule is that "if nobody notices, it's not
>> broken". In a few years? Who knows?
>>
>> So breaking user space is a bit like trees falling in the forest. If
>> there's nobody around to see it, did it really break?
>
> FWIW, I appreciate a lot that non-breaking rule. I have some testing
> machines which boot from PXE or USB on a file-system with some old
> tools and libc, that are both 2.4 and 2.6 compatible. Everything works
> like a charm, the only point of care was to have both module-init-tools
> and modutils (obviously) but even that integrates smoothly.
>
> I know quite a lot of people who never replace user-space but only
> kernels on their systems, so this non-breaking rule is much welcome !

Please don't get me wrong, as a general rule I like it a lot (I almost
never run the stock kernel from a distro and I upgrade kernels _far_ more
frequently than anything else).

However, like every other general rule, there are reasons to make
exceptions.

In this case we are changing the default to make it more secure, I think
that's worth something.

Yes, distros can all add the chmod command to their startup to get similar
behavior. But by the same token, if we change the default, someone running
an old distro can add a chmod command into their bootup to allow their old
software to still work. In the case that has been identified, the problem
is that syslog is unable to get the kernel messages. this can be
important, but in my opinion it's a long way from being a fatal flaw. I've
already seen this sort of problem happen in the wild without this change.
I was running a development version of rsyslog and on a ubuntu system a
year or so ago (before they switched to rsyslog), I had a situation where
firing up rsyslog would generate a lot of messages about being unable to
read the kernel logs (I don't remember the exact message, it wasn't this
kallsyms file, it was something else)

my full-time job is in security for banks, so I'm a bit more sensitive to
the security issues than most people (but tend to agree with Linus about
the security industry and security circus), but I see this as something
that is useful enough to put in (with a compile-time flag if the
compatibility is that critical for this function). I expect that there are
going to be a few more security patches coming down the road that would be
good to put under the same or similar flag (either because they may break
some old software like eliminating /proc/kmem, or because they add a
slight amount of overhead like the nx/read-only patches). As a result I
think something similar to the 'embedded' option would be appropriate,
have these new features on by default, but have some way that people who
need to disable them can do so.

David Lang


\
 
 \ /
  Last update: 2010-11-19 21:59    [W:0.041 / U:5.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site