Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease ofattacking

[david]

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@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/