[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7E2AC2F1-BE59-49C7-A855-7E2FF1990D17@gmail.com>
Date: Thu, 4 Jun 2020 01:51:44 +0300
From: Ilya Matveychikov <matvejchikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: Support for 5.7 linux kernel?
> On Jun 4, 2020, at 12:15 AM, Solar Designer <solar@...nwall.com> wrote:
>
> 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?
>
I see kprobes as a redundant dependency which is OK for the time of
POC-like development, but then it have to be replaced with own hooking
mechanism (probably, configurable at compile-time). And yes, I see the
weak point in using kprobes as the whole LKRG could be disabled by
overwriting few bytes of kernel’s text (see one of lkrg-bypass’es).
[ad]
I can't stop myself from advertising my KHOOK here:
https://github.com/milabs/khook
[/ad]
>> 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.
Then, you may state that whole LKRG project depends on some guy’s decision
who may suddenly decide to remove kprobes from the kernel or disable it for
a distro’s kernel... See the comment below of what I think could make LKRG
popular.
>
> 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.
The phrase "official kernel ABI” always makes me smiling having in mind
how stable it is.
>
>>> 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.
>
Such kind of things like LKRG should support major distros from like CentOS 5
till latest. And I’m pretty sure that targeting could/hosing providers who
provide VPS/VDS services could be the best way to increase LKRG popularity. Also,
there is a big niche which is not covered directly by LKRG but could be covered
by lkrg-“extension” is to secure web-applications by preventing dropping of
web-shells (php) to some filesystem locations like /var/www/html/site/*
Ilya.
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.
