[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Nov 2018 20:40:10 +0400
From: Ilya Matveychikov <matvejchikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG 0.5
> On Nov 12, 2018, at 8:21 PM, Solar Designer <solar@...nwall.com> wrote:
>
> On Mon, Nov 12, 2018 at 08:03:31PM +0400, Ilya Matveychikov wrote:
>> On Nov 12, 2018, at 7:51 PM, Solar Designer <solar@...nwall.com> wrote:
>>> Is the khook_demo module you have loaded part of what you call a LKRG
>>> bypass, or is it some unrelated demo/test you ran? Is it part of what
>>> caused the crash?
>>
>> Quick answer about KHOOK. You can find it at github:
>> https://github.com/milabs/khook
>
> Thanks!
>
>>> If it's part of the bypass, then that wouldn't count per our threat
>>> model unless you loaded the module while under illegitimate root access
>>> obtained via a kernel vulnerability exploit (in which case "ED" is meant
>>> to trigger on module loading attempt). Simple loading of kernel modules
>>> (including custom ones) as legitimate root is allowed under LKRG -
>>> including modules that would substantially modify system behavior (e.g.,
>>> hook functions).
>>
>> And yes, it's a part of bypass where the point is that having protection
>> system (LKRG) and "malicious" module at the same level of abstraction worth
>> nothing to do with the security.
>
> You don't need a video to prove that indeed one can sort of "bypass"
> LKRG by loading a kernel module. This is a case of "works as intended".
> Maybe such video can be useful as illustration to LKRG users on what
> kind of protection not to expect from LKRG. Maybe we also need to
> improve our documentation in that respect - suggestions are welcome - if
> some users would reasonably have different expectations from the way
> LKRG is documented now.
Well, I had no idea about what was the threat model. And you’re right,
bypassing it from the kernel is quite trivial. Now I can understand LKRG
concept better thanks to you.
About the bypass “technique” which I wanted to show I could say that
it can be used from the user-mode too. Just consider that the only way
of LKRG to report something is to write to kernel’s log. So, simple
filtering of entries by “[LKRG]” is enough to completely remove all the
noise produced by LKRG. Valid for both kernel and user modes.
>
> LKRG "main" (unlike "experimental") doesn't include protection against
> root in its threat model, except when said root access was just obtained
> via a kernel vulnerability exploit. I see nothing inconsistent in that.
> Do you? If so, what inconsistency do you see?
Well, it’s a good question. Is it OK for the OS kernel to be exploited
by exploits by itself and this is the case to have things like LKRG or
should the kernel be designed in the way that having a BUG doesn’t give
attacker a way to exploit it?
That’s the only inconsistency I can see.
In other words, probably it’s better to concentrate on fixing OS kernel
security rather than developing of runtime guards :)
>
> To me, that's a reasonable and consistent threat model, even if limited.
>
> 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.
