[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200603174719.GA18725@openwall.com>
Date: Wed, 3 Jun 2020 19:47:19 +0200
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: Support for 5.7 linux kernel?
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.
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.
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.
Alexander
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.
