[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Jun 2020 23:15:33 +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 09:59:30PM +0300, Ilya Matveychikov wrote:
> 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.
Are you referring to the possibility of exploits disabling kprobes?
> Not sure it will be removed from the kernel but it could
> be disabled by default in all major distros
That's a risk for projects like LKRG, yes.
> as it doesn't add a value to the end-user.
It sort of does through enabling LKRG and the like. Maybe LKRG needs
to become more popular for that, though.
On Wed, Jun 03, 2020 at 07:47:19PM +0200, Solar Designer wrote:
> > What was their rationale for no longer exporting kallsyms_lookup_name?
> There was even an article on LWN about the change:
> https://lwn.net/Articles/813350/
Oh, this explains it all. Thank you!
> As being said, it's already unexported. Do you think sharing other point
> of view at LKML for example may change it?
Unlikely, especially given the rationale given in messages referenced
from that LWN article. They're deliberately discouraging modules that
access more than the official kernel ABI.
> > 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.
We continue to support kernels starting with RHEL7's, where LKRG
restricting /proc/kallsyms access or content would make sense.
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.
