[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F57390ED-0B3F-43E1-8121-7DA1A597B1BD@gmail.com>
Date: Wed, 3 Jun 2020 21:59:30 +0300
From: Ilya Matveychikov <matvejchikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: Support for 5.7 linux kernel?
> On Jun 3, 2020, at 8:47 PM, Solar Designer <solar@...nwall.com> wrote:
>
> On Wed, Jun 03, 2020 at 08:30:28PM +0300, Ilya Matveychikov wrote:
>> Yeah, I followed the link you mention right after sending the email. It's
>> a nice trick with kprobes. The funniest thing of all the story with
>> kallsyms_lookup_name() unexport from the kernel is that it doesn't
>> change anything but only breaks some useful out-of-tree projects.
>
> I wonder if they'll want to drop kprobes next... so that we have to
> switch to pattern searches and direct binary patching, which is
> something more acceptable for exploits (with lower requirements for
> robustness) than for protections.
>
I’m not sure that using kprobes is the best choice from the security
point of view as I see it as a fundamental weakness of such products
like LKRG. Not sure it will be removed from the kernel but it could
be disabled by default in all major distros as it doesn’t add a value
to the end-user.
> What was their rationale for no longer exporting kallsyms_lookup_name?
> Where was that discussed? We might want to share our point of view with
> all of the same lists.
>
There was even an article on LWN about the change:
https://lwn.net/Articles/813350/
As being said, it’s already unexported. Do you think sharing other point
of view at LKML for example may change it?
> Personally, I think it's fine security hardening to make /proc/kallsyms
> unreadable except by host system root. In fact, we might want LKRG to
> introduce that policy when it's loaded - this has been on our to-do for
> a while now. However, making kallsyms_lookup_name() not conveniently
> available to kernel modules doesn't seem to serve a valid security
> purpose. Exploits aren't LKMs, so they would probably have to hard-code
> or find that symbol's address (if they need it) by other means anyway,
> so they're not even becoming more complicated with this change.
>
On modern kernels /proc/kallsyms hides kernel addresses to non-root users and
it doesn’t make sense to make it unreadable by non-root users.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
